Credit card system and method

ABSTRACT

A credit card system is provided which has the added feature of providing additional limited use credit card numbers and/or cards. These numbers and/or cards can be used for a single or limited use transaction, thereby reducing the potential for fraudulent reuse of these numbers and/or cards. The credit card system finds application to “card remote” transactions such as by phone or Internet. Additionally, when a single use or limited use credit card is used for “card present” transactions, so called “skimming” fraud is eliminated. Various other features enhance the credit card system, which will allow secure trade without the use of elaborate encryption techniques. Methods for limiting, distributing and using a limited use card number, controlling the validity of a limited use credit card number, conducting a limited use credit card number transaction and providing remote access devices for accessing a limited use credit card number are also provided.

This application is a continuation of U.S. Non-Provisional applicationSer. No. 12/268,063 filed Nov. 10, 2008, which is a continuation of U.S.Non-Provisional application Ser. No. 10/160,178 filed Jun. 4, 2002,which is a continuation-in-part of U.S. Non-Provisional application Ser.No. 09/506,830 filed Feb. 18, 2000, which in turn is acontinuation-in-part of U.S. Non-Provisional application Ser. No.09/235,836 filed Jan. 22, 1999. This application claims the benefit ofU.S. Provisional Application No. 60/295,020 filed Jun. 4, 2001; U.S.Provisional Application No. 60/120,747 filed Feb. 18, 1999; U.S.Provisional Application No. 60/134,027 filed May 13, 1999; U.S.Provisional Application No. 60/144,875 filed Jul. 20, 1999; U.S.Provisional Application No. 60/147,153 filed Aug. 4, 1999; U.S.Provisional Application No. 60/099,614 filed Sep. 9, 1998; U.S.Provisional Application No. 60/098,175 filed Aug. 26, 1998; U.S.Provisional Application No. 60/092,500 filed Jul. 13, 1998; IrishApplication No. S98 0458 filed Jun. 15, 1998; Irish Application No. S980346 filed May 5, 1998; Irish Application No. S98 0223 filed Mar. 25,1998. The entire contents of each of these applications are incorporatedherein by reference.

BACKGROUND

1. Field of the Invention

This invention relates to a credit card system and method, and moreparticularly, to a credit card system and method offering reducedpotential of credit card number misuse.

2. Related Art

The development of retail electronic commerce has been relatively slowin spite of the perceived demand for such trade. The single greatestdeterrent to the expansion of retail electronic commerce is perceived tobe the potential for fraud. This potential for fraud has been a majorconcern for the credit card companies and financial institutions as wellas the customers and the providers of the goods and services.

The former are concerned about fraud because essentially the financialinstitutions have to bear the initial cost of the fraud. Additionally,the credit card companies have an efficient credit card system which isworking well for face to face transactions, i.e., “card present”transactions where the credit card is physically presented to a traderand the trader can obtain the credit card number, compare signatures andin many cases photographs before accepting a particular credit card.

The latter are equally concerned about fraud being well aware thatultimately the user must pay for the fraud. However, there areparticular personal concerns for the consumer in that the fraudulent useof the credit card by misuse of the credit card number by a third partymay not become apparent for some time. This can happen even if the cardis still in his or her possession. Further, when fraud does occur theconsumer has the task of persuading the credit card provider that fraudby another did indeed occur.

There is also the additional fear of being overcharged on a credit card.There are thus particular risks for those credit card holders who haverelatively high spending limits, in that if fraud should occur, it maybe some considerable time before it is detected. One particular form offraud referred to as “skimming” is particularly difficult to control.What happens is the card holder proffers his or her card at anestablishment to make a transaction, the relevant information iselectronically and/or physically copied from the card and the card issubsequently reproduced. This can be a problem with travelersparticularly during an extensive period of travel as the fraudulent cardmay turn up in other places and it may be some considerable time beforethe fraud is detected.

For remote credit card use, the credit card holder has to providedetails of name, master credit card number, expiration date and addressand often many other pieces of information for verification; the storingand updating of the information is expensive but necessary. This ofitself is a considerable security risk as anybody will appreciate thatthis information could be used to fraudulently charge goods and servicesto the card holder's credit card account. Such fraudulent use is notlimited to those people to whom the credit card information has beengiven legitimately, but extends to anybody who can illegitimately obtainsuch details. A major problem in relation to this form of fraud is thatthe credit card may still be in the possession of the legitimate holderas these fraudulent transactions are taking place. This is oftenreferred to as “compromised numbers” fraud. Indeed all this fraud needsis one dishonest staff member, for example in a shop, hotel orrestaurant, to record the credit card number. It is thus not the same ascard theft.

The current approaches to the limiting of credit card fraud aredependent on the theft of a card being reported and elaborateverification systems whereby altered patterns of use initiate someinquiry from the credit card company. Many users of credit cards have nodoubt received telephone calls, when their use of the card has beenexceptional, or otherwise unusual in the eyes of the organizationproviding the verification services.

Thus, there have been many developments in an effort to overcome thisfundamental problem of fraud, both in the general area of fraud forordinary use of credit cards and for the particular problems associatedwith such remote use.

One of the developments is the provision of smart cards which are creditcard devices containing embedded electronic circuitry that can eitherstore information or perform computations. Generally speaking theycontribute to credit card security systems by using some encryptionsystem. A typical example of such a smart card is disclosed in U.S. Pat.No. 5,317,636 (Vizcaino).

Another one of the developments is the Secure Electronic Transaction(SET) protocol which represents the collaboration between many leadingcomputer companies and the credit card industry which is particularlyrelated to electronic transmission of credit card details and inparticular via the Internet. It provides a detailed protocol forencryption of credit card details and verification of participants in anelectronic transaction.

Another method that is particularly directed to the Internet isdescribed in U.S. Pat. No. 5,715,314 (Payne et al.). U.S. Pat. No.5,715,314 discloses using an access message that comprises a productidentifier and an access message authenticator based on a cryptographickey. A buyer computer sends a payment message that identifies aparticular product to a payment computer. The payment computer isprogrammed to receive the payment message, to create the access message,and to send the access message to a merchant computer. Because theaccess message is tied to a particular product and a particular merchantcomputer, the access message can not be generated until the user sendsthe payment message to the payment computer. Because the access messageis different from existing credit card formats, the access message isill-suited for phone/mail orders and other traditional credit cardtransactions.

U.S. Pat. No. 5,883,810 (Franklin et al.) describes an onlinetransaction system in which a user of the Internet or the like clicks onan icon to receive a proxy transaction number from a credit cardprovider. This proxy number stands in for the user's regular credit cardnumber during transmission over the Internet, but expires after a shorttime (e.g., one hour) to reduce the chance that the number will beeffectively intercepted and fraudulently used. The processing thatoccurs when a bank receives transaction information from a merchantinvolves checking whether the proxy number is a valid number and whetherthe transaction value and merchant match. There is no additionalprocessing triggered when the bank processing system receives the proxynumber. In addition, a significant drawback of the Franklin et al.system is that an unscrupulous merchant or a criminal who is capable ofaccessing or intercepting order details can then turn around and use theproxy number a number of times before the lapse of the expiration term.Thus, more than one transaction can occur within the duration of theexpiration term. The Franklin et al. system has nothing in place toprevent this type of fraud. The Franklin et al. system merely dependsupon an assumption that fewer criminals could obtain the proxy numberand reuse it within the expiration term of the proxy transaction numberset by the issuing bank than the total number of criminals capable ofgaining access to credit card numbers used for online commerce. Also,the inclusion of specific transaction information does not prevent afraudulent merchant from recurrent unauthorized charges within theexpiry time of the proxy number. The user will not be aware of thismisuse of his/her credit card details until the receipt of thestatement, which will typically not be until several weeks later.

There are also specific electronic transaction systems such as “CyberCash,” “Check Free” and “First Virtual.” Unfortunately, there areperceived problems with what has been proposed to date. First, any formof reliance on encryption is a challenge to those who will then try tobreak it. The manner in which access has been gained to extremelysensitive information in government premises would make anyone wary ofany reliance on an encryption system. Second, a further problem is thatsome of the most secure forms of encryption system are not widelyavailable due to government and other security requirements. Limitingthe electronic trading systems and security systems for use to theInternet is of relatively little use. In addition, entirely newelectronic payment systems require changes in how merchants handletransactions and this represents an important commercial disadvantagefor such systems.

Additionally, various approaches have been taken to make “card present”transactions more attractive. For instance, Japanese Patent PublicationNo. Hei 6-282556 discloses a one-time credit card settlement system foruse by, e.g., teenage children of credit card holders. This systememploys a credit card which can be used only once in which variousinformation such as specific personal information, use conditions, andan approved credit limit identical to those of the original credit cardare recorded on a data recording element and displayed on the face ofthe card. The one-time credit card contains the same member number,expiration date, card company code, and the like as on existing creditcard, as well as one-time credit card expiration date not exceeding theexpiration date of credit card, available credit limit for the card, andthe like. The one-time credit card makes use of some of the samesettlement means as the conventional credit card. However, the systemalso requires use permission information to be recorded on the creditcard, the information permitting the credit card to be used only once ormaking it impossible to use the credit card when the credit limit hasbeen exceeded. A special card terminal device checks the informationtaken from the card for correctness and imparts use permissioninformation for when the card is not permitted to be used on thetransmission to the credit card issuing company. The use permissioninformation takes the form of a punched hole on the card itself. Thissystem has obvious drawbacks, such as the card terminal having to bemodified for additional functions (e.g., punching holes, detectedpunched holes, imparting additional information, etc.). Also, such asystem offers little additional security insofar as fraud can still bepracticed perhaps by covering the holes or otherwise replacing thepermission use information on the credit card. Further, such a systemwould require a change in nearly all card terminal equipment if it wereadopted.

U.S. Pat. Nos. 5,627,355 and 5,478,994 (Rahman et al.) disclose anothertype of system that uses a plurality of pin numbers which are added to acredit card number on an electronic display. U.S. Pat. No. 5,627,355discloses a credit card having a memory element containing a series ofpasswords in a predetermined sequence. These passwords are identical toanother sequence stored in a memory of a host control computer. Further,the card contains a first fixed field containing an account number(e.g., “444 222 333”). In operation, the memory element of the creditcard device provides a unique password from the sequence with each useof the credit card device. This permits verification by comparing theaccount number and the password provided with each use of the devicewith the account number and the next number in sequence as indicated bythe host computer. The host computer deactivates the password after thetransaction. Among the drawbacks with this type of system is the needfor a power supply, a display, a memory device, a sound generator andthe need to recycle a limited sequence of pin numbers. Such a system isnot readily adapted to current credit card transactions because it lacksthe ability of providing a check sum of the card number and cannot beread by a standard card reader. Also, if the card is lost or stolen,there is little to prevent a person from using the card until it isreported to be lost or stolen by the correct holder. See, also, U.S.Pat. No. 5,606,614 (Brady et al.).

Other attempts have been made to make funds available to an individual,but with limitations. For example, U.S. Pat. Nos. 5,350,906 (Brody etal.) and 5,326,960 (Tannenbaum et al.) disclose issuing temporary PINsfor one time or limited time and limited credit access to an account atan ATM. These patents disclose a currency transfer system and method foran ATM network. In this system, a main account holder (i.e., thesponsor) sets up a subaccount that can be accessed by a non-subscriberby presenting a fixed limit card associated with the subaccount and byentering a password corresponding to the subaccount. Once the fixedlimit is reached, the card can no longer be used. The fixed limit cardcontains information on its magnetic stripe pertaining to the sponsoraccount.

One of the problems with all these systems is that there are manycompeting technologies and therefore there is a multiplicity ofincompatible formats, which will be a deterrent to both traders andconsumers. Similarly, many of these systems require modifications of thetechnology used at the point of sale, which will require considerableinvestment and further limit the uptake of the systems.

OBJECTS AND SUMMARY OF THE INVENTION

Many solutions have been proposed to the problem of security of creditcard transactions. However, none of them allow the use of existingcredit cards and existing credit card formats and terminal equipment inthe exiting credit card system, which includes provisions forcharge-backs, etc. Ideally, as realized by the present inventors, thesolution would be to obtain the functionality of a credit card, whilenever in fact revealing the master credit card number. Unfortunately,the only way to ensure that master credit card numbers cannot be usedfraudulently is to never transmit the master credit card number by anydirect route, i.e., phone, mail, Internet or even to print out themaster credit card number during the transaction, such as is commonlythe case at present.

According to exemplary embodiments of the invention as described in U.S.non-provisional application Ser. Nos. 09/235,836 and 09/506,830, a moresecure way of using existing credit cards and, in particular, usingexisting credit cards in remote credit card transactions was provided.These earlier applications were specifically directed towards providinga more secure way of using existing credit cards generally which willnot require any major modifications to existing credit card systems. Itis further directed towards providing a credit card system that will beuser friendly and will provide customers with a greater confidence inthe security of the system.

The present invention includes a number of credit card products, whichhave predefined characteristics.

These and other advantages of the present invention are satisfied by afirst exemplary embodiment, which pertains to a financial transactionsystem capable of using at least one limited use credit card number,which is limited in use by a party other than a limited use credit cardnumber issuer and which is associated the master account number of acustomer. The inventive method of controlling the validity of thelimited use credit card number comprising the steps of: sending to auser from a limited use credit card number issuer a limited use creditcard number; communicating with a limited use card number card issuer toestablish limitations on the use of the limited use credit card numberby a third party before it can be used in a transaction by said user;and authorizing transactions which meet said established limitations anddenying other transactions by comparing at a central location theattempted use to the established limitations on use.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing, and other, objects, features and advantages of thepresent invention will be more readily understood upon reading thefollowing detailed description in conjunction with the drawings inwhich:

FIG. 1 shows an exemplary system for implementing the present invention;

FIG. 2 shows, in high-level form, the operation of the centralprocessing station shown in FIG. 1;

FIG. 3 is a flow chart illustrating an exemplary process for allocatingcredit card numbers;

FIG. 4 is a flow chart illustrating an exemplary process for limitingthe use of a credit card number;

FIG. 5 is a flow chart illustrating an exemplary process fordistributing credit card numbers;

FIG. 6 is a flow chart illustrating an exemplary process forelectronically using credit card numbers;

FIG. 7 is a flow chart illustrating an exemplary process for processinga transaction;

FIG. 8 is a flow chart illustrating another exemplary process forprocessing a transaction;

FIG. 9 is a flow chart illustrating an exemplary method of controllingthe validity of a limited use credit card number;

FIG. 10 is a flow chart illustrating an exemplary process for using acredit card number as a PIN number;

FIG. 11 is a block diagram illustrating an exemplary location for thecentral processing system;

FIG. 12 is a flow chart illustrating an exemplary method of conducting alimited use credit card number transaction;

FIG. 13 is a flow chart illustrating an exemplary method of conducting asettlement transaction;

FIG. 14 is a block diagram illustrating an alternate exemplary locationfor the central processing system;

FIG. 15 is a block diagram illustrating an alternate exemplary processfor limiting, distributing and using a limited use card number;

FIG. 16 is a flow chart illustrating an exemplary method of providingremote access devices for accessing limited use credit card numbers; and

FIG. 17 is a diagram illustrating how the present invention can placelimitations on an configurable plastic payment card to facilitatecard-present applications.

DETAILED DESCRIPTION

In this specification the term “credit card” refers to credit cards(MasterCard®, Visa®, Diners Club®, etc.) as well as charge cards (e.g.,American Express□, some department store cards), debit cards such asusable at ATMs and many other locations or that are associated with aparticular account, and hybrids thereof (e.g., extended payment AmericanExpress®, bank debit cards with the Visa® logo, etc.) or any otherpresent or future financial transaction card having similarcharacteristics. Also, the terms “master credit card number” and “mastercredit card” refer to the credit card number and the credit card asgenerally understood, namely, that which is allocated by the credit cardprovider to the customer for his or her account for multiple uses for arenewable period and a credit limit. It will be appreciated that anaccount may have many master credit cards in the sense of thisspecification. For example, a corporation may provide many of itsemployees with credit cards but essentially each of these employeesholds a master credit card even if there is only one customer account.Each of these master credit cards will have a unique master credit cardnumber, which set of master credit card numbers will be linked to theaccount. Similarly, in families, various members of the family may holda master credit card, all of which are paid for out of the one customeraccount.

Additionally, the “master credit card” account can be in someembodiments something other than a credit card account. For instance,while not otherwise affecting the formatting or processing of thelimited use credit card numbers as described herein, the master cardnumber can be a prepaid account or another type of account, such as autility, telephone service provider or Internet Service Provider (ISP)account. The utility company, telephone company, ISP or other accountholder would generate a bill, which, in possible addition to or separatefrom to the regular bill, would include a listing of limited use creditcard transactions. An advantage of this type of arrangement is that theservice provider already has information as to a pool of individual andtheir credit worthiness, as well as low increased overhead due to thealready in place billing system. In these embodiments, the “masteraccount” may but likely does not have the format of a standard creditcard or the like.

The term “limited-use” credit card number is used to encompass at leastboth the embodiment in which the credit card is designated for a singleuse, and the embodiment in which the credit card is designated formultiple uses providing that the charges accrued do not exceed aprescribed threshold or thresholds, such a total single charge, totalcharges over a limited time period, total charge in a singletransaction, etc. A common feature is that the limited use credit cardnumber is deactivated upon satisfaction of a limited-use condition, andnot just the expiration date of the card. Stated differently, the alimited-use credit card number is deactivated upon a use-triggeredcondition which occurs subsequent to assignment of said at least onecredit card number.

The term “deactivated” means that new transactions cannot be initiatedusing the same limited-use credit card number, but the limited-usecredit card number is still available for further activity related tothe original transaction, such as for charge-backs where an account iscredited, such as upon return of unaccepted merchandise.

The terms “card holder” and “user” are used interchangeably to refer toan entity, e.g., an individual, that has been rightfully issued acredit/debit/charge card number, e.g., through a contractualarrangement, or that has been authorized to use such card by such entityor a representative of such entity.

1. Overview of System Features

There are at least two basic different ways of carrying out the presentinvention. In summary, the two ways are the allocation of additionalcredit card numbers for remote trade and the provision of what areeffectively disposable credit cards for remote and card present trade,both of which have the feature of in the case of single use or in thecase of multiple use, protecting against the worst effects ofcompromised numbers fraud or skimming.

In a refinement of the invention, it is possible to control the mannerin which an actual transaction is carried out as a further protectionagainst unscrupulous providers of goods and services.

Essentially, there are certain matters that will be considered inrelation to this invention. They are the operational or functionalfeatures in so far as they affect customers, and then there are thetechnical features, namely how the invention is implemented, how theinvention is provided to the customers, and finally, how the inventionis handled by the providers of goods and services and the processors ofthe credit cards, i.e., the financial institutions and/or their serviceproviders.

The operational or functional features of this invention will bediscussed first in the context of a standard credit card system.

One basic feature of the invention is to provide in a credit card systemsuch that each master credit card holder could be provided with one ormore of the following: 1) additional single use credit card numbers forremote transactions; 2) multiple use credit card numbers for remotetransactions; 3) single use additional credit cards for remote and cardpresent transactions; and 4) multiple use credit cards for remote andcard present transactions.

It is also envisaged that in certain situations credit cards can beprovided to people who do not have an account with any credit cardcompany. This latter feature is described in more detail below. Variousother features may be provided in the above situations, which willfurther improve the security of credit card transactions.

Dealing first with the situation where a master credit card holder hasan additional credit card number allocated to him or her for a singleuse, it will be appreciated that since the number can only be used forone single transaction, the fact that the number is in anybody else'shands is irrelevant as it has been deactivated and the master creditcard number is not revealed to the third party. Various other featuresmay be added to such single use credit card numbers, for example, thevalue of the transaction can be limited, thus the master credit cardholder can have a plurality of single use credit card numbers ofdiffering values. For example, when a remote trade is carried out, themaster credit card holder will use a credit card number which has acredit card limit only marginally above or equal to that of the value ofthe transaction. This would reduce the chances of or prevent anunscrupulous trader using the credit card number to supply additionalgoods or services over those ordered or to increase the agreed charge.

A second embodiment of the invention provides the master credit cardholder with an additional credit card number for use in remote trade,which credit card number could have, as in the previous example of theinvention, a credit limit for each specific transaction or a creditlimit such that when the aggregate amount of a series of transactionsexceeded a specific credit limit that the credit card number would becanceled, invalidated or in some other way deactivated. Similarly, themultiple use credit card number could be limited to, for example, fiveuses with a credit limit not exceeding $100 in each transaction and anaggregate credit limit not exceeding $400. Similarly, a time restrictioncould be put on such a credit card number in that it would bedeactivated if it was used with frequency above (or below) a giventhreshold, for example, more than once a week. These limits andrestrictions on the use of a limited-use credit card number can be andnormally would be controlled by the consumer, such as the card holder ora person overseeing a card holder's use (e.g., a parent, employer, giftgiver, etc.). Hence, for limited-use credit card number, the limitationsof which are defined by a consumer rather than a card issuer, the termControlled Payment Number, or CPN has been coined.

It will be appreciated that the limits that can be placed on the use ofa single use credit number or a multiple-use credit card number or CPNare almost limitless and those having skill in the art will considerother ways in which the use of the credit card number could be limited,whether it be by time, by amount, frequency of use, by geographicalregion, by merchant, by merchant class, or by purpose or use (such aslimited to Internet trade and so on), or by some combination of theseseparate criterion.

The third way in which the invention could be carried out is byphysically providing additional single use credit cards each of whichwould have a unique additional credit card number. Such additionalsingle use credit cards could then be used both for remote trade byusing the additional credit card numbers for respective transactions,and for “card present” trade where each card would be “swiped” in thenormal manner. Such a disposable credit card could be made like anycommon credit card, or from a relatively inexpensive material, such ascardboard or thin plastic, with the relevant information entered into itin readable (e.g., magnetic) form, as is already the case with manyforms of passes for use in public transport and the like. Again,substantially the same features as with the credit card number could beprovided. Thus, for example, the disposable credit card could be limitedto use geographically, to a use, to an amount, to a frequency of use, toan expiration date, and so on. Again, those skilled in the art willappreciate that there are many variations to this concept.

Another way of carrying out the invention is to provide a master creditcard holder with a multiple-use additional credit card, where theadditional credit card provides any limitations as to limited-usetriggering conditions that may be desired.

Ideally, irrespective of the manner in which the invention is carriedout, the master credit card holder would be provided with either aplurality of single use additional credit card numbers or multiple-usecredit card numbers or a mixture of single and multiple-use creditscards. Several specific products are described in the last section ofthe present application.

It will be appreciated that with either single use credit card numbersor single use additional credit cards, it is possible to eliminate orreduce the risk of credit card number fraud. Further, depending on thecredit limit imparted to the particular credit card number or additionalcredit card number or single use additional credit card, it is possibleto further limit the possibilities of fraud in any remote transactionand that with the use of a disposable single use credit card it ispossible to eliminate or reduce the risk of skimming.

With multiple use additional credit card numbers and multiple useadditional credit cards, the above-identified problems may not betotally eliminated due to preferences of the user. This is because, incertain circumstances, credit card users may prefer to have, forexample, an additional credit card number for remote trade with aspecific credit limit that they use all the time and are willing to takethe risk of compromised number fraud, in the sense that they can controlthe severity of this misuse. This would be particularly the case wheresome of the various user triggered limitations suggested above are usedwith the additional credit card number. Substantially the same criteriawould apply to an additional multiple use credit card.

Effectively, the present invention solves the problem by obtaining thefunctionality of a credit card while never in fact revealing the mastercredit card number as the master credit card number need never be givenin a remote transaction. Further, the master credit card itself neednever be given to a trader.

In another embodiment of the invention, it is envisaged that people whodo not hold master credit cards could purchase disposable credit cardswhich would have a credit limit for the total purchases thereon equal tothe amount for which the credit card was purchased. These could then beused for both card present and card remote trade, the only proviso beingthat if the credit limit was not reached it will then be necessary for arefund to be given by the financial institution or credit card provider.An obvious way of obtaining such a refund would be through an automaticteller machine (ATM). In this way, the existing credit card transactionsystem is employed and the card holder is given the convenience ofhaving a credit card.

As an alternative, the above-discussed cards could be, in effect, debitcards in the true sense, in which funds are withdrawn against acustomer's account. In this case, the “credit card” issued, whether itbe a one time use card or multi-use card, and whether have a creditlimit or not, would be used to debit the account immediately.Preferably, the credit card issued in these circumstances would besingle use with or without a transaction amount limit which would beused and processed by the customer and merchant for a transaction as ifit were a credit card, while in the customer's bank it would be treatedlike any other debit to the account.

2. Exemplary Implementation

2.1 Implementation Overview

Various aspects of the invention may be embodied in a general purposedigital computer that is running a program or program segmentsoriginating from a computer readable or usable medium, such mediumincluding but not limited to electrical or magnetic storage media (e.g.,ROMs, EEPROMs, RAM, floppy disks, hard disks, etc.), optically readablemedia (e.g., CD-ROMs, DVDs, etc.), and carrier waves (e.g.,transmissions over the Internet) or combinations thereof. A functionalprogram, code and code segments, used to implement the present inventioncan be derived by a skilled computer programmer from the description ofthe invention contained herein.

FIG. 1 shows an exemplary overview of a system for implementing thelimited use credit card system of the present invention. The system 100comprises a central processing station 102, which, accordingly toexemplary embodiments, may be operated by the credit card provider.Generally, this station 102 receives and processes remotely generatedcredit card transactions. The credit card transactions can originatefrom a merchant in the conventional manner, e.g., by swiping a creditcard through a card swipe unit 106. Alternatively, the credit cardtransaction requests can originate from any remote electronic device 104(e.g., a personal computer). These remote devices can interface with thecentral processing station 102 through any type of network, includingany type of public or propriety networks, or some combination thereof.For instance, the personal computer 104 interfaces with the centralprocessing station 102 via the Internet 112. Actually, there may be oneor more merchant computer devices (not shown) which receive credit cardtransactions from the remote electronic device 104, and then forwardthese requests to the central processing station 102. The centralprocessing station 102 can also interface with other types of remotedevices, such as a wireless (e.g., cellular telephone) device 140, viaradio communication using transmitting/receiving antenna 138. Otherintermediary components can be interposed, as is conventional.

The central processing station 102 itself may include a centralprocessing unit 120, which interfaces with the remote units via networkI/O unit 118. The central processing unit 120 has access to a databaseof credit card numbers 124, a subset 126 of which can be designated asbeing available for limited use (referred to as the “available range”).Also, the central processing unit 120 has access to a central database122, referred to as a “conditions” database. This database is a generalpurpose database which stores information regarding customers' accounts,such as information regarding various conditions which apply to eachcustomers' account. Further, this database 122 may store the mappingbetween a customer's fixed master credit card number and any outstandingassociated limited use credit cards, using, for instance, some type oflinked-list mechanism. Databases 122 and 124 are shown separately onlyto illustrate the type of information which may be maintained by thecentral processing station 102; the information in these databases canbe commingled in a common database in a manner well understood by thosehaving skill in the data processing arts. For instance, each limited usecredit card number can be stored with a field, which identifies itsmaster account, and various conditions regarding its use.

The central processing unit 120 can internally perform the approval anddenial of credit card transaction requests by making reference to credithistory information and other information in the conventional manner.Alternatively, this function can be delegated to a separate clearanceprocessing facility (not shown).

Finally, the central processing station includes the capability oftransmitting the limited use credit card numbers to customers. In afirst embodiment, a local card dispenser 128 can be employed to generatea plurality of limited use cards 132 and/or a master credit card 134 fordelivery to a customer. In a second embodiment, the limited use creditcard numbers can be printed on a form 136 by printer 130, which is thendelivered to the customer via the mail. The printed form 136 may includematerial which covers the numbers until scratched off, therebyindicating what numbers have been used and are no longer active. Thislisting of numbers can be included in a monthly or other periodicaccount statement sent to the customer. In a third embodiment, theselimited use numbers can be electronically downloaded to a user'spersonal computer 104, where they are stored in local memory 142 of thepersonal computer 104 for subsequent use. In this case, the credit cardnumbers can be encrypted (described in detail later). Instead of thepersonal computer 104, the numbers can be downloaded to a user's smartcard though an appropriate interface. In a fourth embodiment, thesingle-use credit card numbers can be downloaded to a radio unit 140(such as a portable telephone) via wireless communication. In a fifthembodiment, an ATM 108 can be used to dispense the limited use cards110. Those skilled in the art will readily appreciate that other meansfor conveying the numbers/cards can be employed. These embodiments are,of course, usable together.

The logic used to perform the actual allocation and deactivation oflimited use credit card numbers preferably comprises a microprocessor,which implements a stored program within the central processing unit120. Any general or special purpose computer will suffice. Inalternative embodiments, the logic used to perform the allocation anddeactivation of the limited use credit card numbers may comprisediscrete logic components, or some combination of discrete logiccomponents and computer-implemented control.

FIG. 2 shows a high-level depiction of the functions performed by thecentral processing station 102 or the like. The process begins in step202 by allocating one or more limited use numbers to a customer. Thesenumbers are ultimately selected from the list 126 of available limiteduse numbers, or some other sub-set list which has been previously formedfrom the numbers in list 126. Also, although not shown in FIG. 2, amaster account number would have been preferably assigned to thecustomer at a previous point in time. The conditions database 122 maycomprise a mechanism for associating the master account number (whichcan be a credit card number or some other type of account) number withthe limited use credit card number. Because the limited use cards arearbitrarily chosen from the listing 126 of limited use card numbers,there should be no discernable link which would allow anyone todetermine the master credit card number from any of the limited usenumbers.

The processing then advances to step 204, where it is determined whethera customer requests or an event triggers a request for additionallimited use cards or card numbers. If so, additional limited use cardsor card numbers are allocated to the customer.

Processing then advances to step 206, where the central processingstation determines whether a transaction has taken place using apreviously issued limited use card. This step is followed by adetermination (in step 208) whether the limited use number should bedeactivated. For instance, if the card is a single-use card, it will bedeactivated. If the card is a fixed-limit card, the card is onlydeactivated if the recent transaction exceeds some stored thresholdlimit. These threshold limits can be stored on the card itself or in theconditions database 122. The actual step of deactivating is performed bygenerating a deactivation command, as represented in step 210 shown inFIG. 2. Naturally, there are other steps to processing a credit cardtransaction, such as checking whether the card is deactivated orotherwise invalid prior to completing the transaction. These additionalsteps are system specific and are not discussed here for sake ofbrevity.

Once a number is deactivated, this number can not be fraudulentlyreused. Hence, the risk of fraudulent capture of these numbers over theInternet (or via other transmission means) effectively disappears. In analternative embodiment of the invention, these deactivated numbers canbe reactivated providing that a sufficiently long time since their firstactivation has transpired. Providing that there is a sufficiently largenumber of limited use credit card numbers to choose from, it would bepossible to wait a long time before it was necessary to repeat anynumbers. At this point, it would be very unlikely that someone who hadwrongfully intercepted a credit card number years ago would be motivatedto fraudulently use it before the rightful owner.

After the limited use card is deactivated or a number of limited usecards are deactivated, an additional limited use card or cards can beactivated. As described in detail in the following section, the actualactivation of the credit card number can involve various intermediateprocessing steps. For instance, the credit card numbers from the list126 can be first allocated to an “allocated” range of numbers, and thento an “issued but not valid” range of numbers, and then finally to an“issued and valid” range of numbers. FIG. 2 is a high-level depiction ofthe process, and encompasses this specific embodiment, as well as themore basic case where the credit card numbers are retrieved from adatabase and then immediately activated.

Having set forth a summary of how the invention can be implemented,further details are provided in the following.

2.2 Allocation of the Credit Card Numbers

The first thing that the credit card provider may do is to generate alist of additional credit card numbers, whether they be single use ormultiple use, and allocate additional credit numbers to a master creditcard as a further credit card number for optional use instead of themaster credit card number. Such a list can be produced by any suitablesoftware package in the exemplary manner discussed in more detail below.Because the numbers allocated to a particular master credit card holderwill not have any link to the master credit card number, the mastercredit card number should not be able to be derived from the additionalcredit card numbers.

In effect, randomness in credit card numbers is provided by the factthat there is a queue formed by the customers requiring numbers.Further, it should not be possible, even knowing the additional creditcard numbers in a particular master credit card holder's possessionwhich he or she may have used, to predict the next set of numbers thatthat particular master credit card holder will be allocated, since therewill be randomness of access to additional credit card numbers in thetruest sense. Even if the credit card provider were to allocate numberssequentially, there would be no way of predicting the number that thatcredit card holder would subsequently acquire, since the numbers wouldbe allocated by virtue of a queue, the randomness of this allocationbeing such as to prevent any prediction.

As such, the credit card numbers generated by the central computer neednot be per se random numbers. Preferably, though, these numbers arevalid credit card numbers with the constraint that they must conform toindustry specifications of the format in terms of their numericalcontent in such a way that they can be handled with no (or minimal)modifications by merchant/acquiring systems and networks and be routedto the appropriate center for processing. An additional constraint isthat they must be different from all other conventional account numbersand all other single use numbers during their lifetime of validity.These constraints are practical requirements to produce a commerciallyviable system, which would likely not be satisfied by any process thatgenerates random numbers in isolation.

To achieve these allocation requirements, an issuing bank decides withinits total available range of credit cards to allocate a certain range orranges of numbers to the single use system, referred to herein as the“available range.” This may represent spare numbers using existingheader sequences (e.g., the sequence of usually 4-6 digits that definethe issuing institution and are used to route the card to theappropriate transaction processor) or within newly created headersequences. The numbers not allocated include existing credit cardaccounts for that issuer and sufficient spare capacity for new accountholders and replacement numbers for existing customers. The additionalnon-embossed components of the card details and any card specificinformation that is transmitted during a transaction may be varied fromcard to card to enhance security and privacy of credit cardtransactions.

Although each limited use number is unique during the its lifetime ofvalidity, information required to route the card number and transactiondetails to the appropriate processor is maintained to ensure thatlimited use numbers are processed appropriately. However, the limiteduse numbers do not need to include either the master card account numberor an encoded version of the account number. Indeed privacy and securityare enhanced when no unique account holder identifier is included withinthe limited use credit card number.

Also, information that is verified prior to the card being processed forauthorization and payment, such as expiry date and checksum digit mustbe valid. This information may vary from limited use number to limiteduse number, but must be valid to ensure that the number passes checksthat may be completed within the merchant terminal, i.e., the checksumis appropriately calculated for each limited use number and theassociated expiry date is valid at the time of use.

Within the constraint of using a valid credit card format, the randomallocation process used to generate lists of unique limited use numberscan involve allocation from a range of numbers in which either theentire number or portions of the account number are varied. In addition,the allocation can include combinations of all or part of the accountnumber together with all or part of additional information such asnon-embossed additional numbers, expiry date and other information thatidentifies the card and is passed on by the merchant to the cardprocessor during a transaction.

Sequential random allocation from a list of available validcredit/debit/charge card codes that have been solely allocated for useas limited use numbers ensures that the criteria specified for limiteduse numbers are met, i.e., no two limited use numbers are the same, nolimited use number is the same as an existing account number, and nonewly issued conventional card number is the same as a previously issuedlimited use number. To achieve true computational independence betweenaccount numbers and limited use cards and between limited use numbersfor the same account, the random allocation process requires a trulyrandom seed value. Such true randomness can be obtained from aphysically random system with well-defined properties such as a whitenoise generator. An analog to digital converter that receives an analogsignal from such a truly random physical system can be used to ensuretruly random allocation.

Other approaches can result in the same result with lower computationalefficiency. For example the allocation process could randomly selectvalid credit card numbers within the entire range for a given cardissuer and then discard the number if it is already in use as a limiteduse or conventional card number or if the same number was allocatedwithin a given time frame.

The above process generates a series of available single use numbers. Torepeat, the allocation process is achieved by a truly random (or lessideally a pseudo random) mapping process in which a single use number israndomly selected and then assigned to a selected account holder (eitheran existing credit/debit card holder, a new solely single use accountholder or a bank account). Additional single use numbers can beallocated for purchase on an individual basis. Each assigned single usenumber is then removed from the sequence of available numbers before thenext allocation, ensuring a unique allocation of each single use number.An alternative mechanism for performing direct allocation to a specificaccount holder is for lists of single use numbers to be allocated tounique storage locations. The list from a specific storage location canthen be directly allocated to a given account at a later date. Thisallows for rapid allocation of cards to new customers without any delayarising from the need to perform a new allocation procedure for each newcustomer.

This allocation process generates another series of single use numbers,the “allocated range” with an associated identification field todetermine how the account will be settled once used, i.e., onto whoseaccount the transaction will be charged. The allocation process canoccur a significant time before the single use numbers are required.Once allocated, they are not added into the list of valid accounts untilrequired by the user.

FIG. 3 is a flow chart illustrating an exemplary process for allocatingcredit card numbers. A central processing unit (CPU) generates adatabase of credit card numbers (step 302), and may select a mastercredit card number. (Step 304). In step 306, the CPU checks to make surethat the master credit card number is not the same as another creditcard number. The CPU selects additional credit card numbers to allocateto the master credit card number or other type of account number. (Step308). The CPU can use any of the techniques discussed above to selectthe additional numbers. In step 310, the CPU checks to make sure thatthe additional numbers are not the same as another credit card number.The additional numbers can be used, for example, for single use cards.

When a customer needs multiple-use cards, the CPU can issue theadditional credit card numbers to the customer. Unless thesemultiple-use numbers are issued directly into the hands of the customer(e.g., by an automated teller machine (ATM)), they are not directlyadded to the list of valid account numbers held within the centralcomputer system. These numbers are added to an “issued, but not valid”list of numbers. (Step 312). The number of multiple-use numbers issuedat one time depends upon the rate at which the customer will use thecards and the capability of the device used to store the multiple-usenumbers until used. The CPU can provide the customer with enoughmultiple-use numbers to fulfill their multiple-use purchase requirementsfor up to, for example, 2 years. Each multiple-use number can be endowedwith specific restrictions in terms of transaction type or value,provided that these properties do not exceed the restrictions placed upon the customer's account (such as the available credit balance).

Once a series of multiple-use numbers are issued, the user has theoption of confirming receipt by telephone or other communication mediabefore any of the issued numbers become validated on the processingsystem. (Step 314). Once receipt has been confirmed (or assumed), notevery issued multiple-use number is necessarily added to the “issued andvalid” list. (Step 316). To prevent excessive valid multiple-use numbersbeing held within the processing system, the number of multiple-usenumbers declared to be valid at any one time is limited to account forwaste of numbers (i.e., numbers that are accessed by a customer but arenever used to complete a transaction) and to allow for time delaysbetween different transactions leading to differences in the sequence inwhich multiple-use numbers are accessed by the customer and the sequencein which they arrive at the processing center. The maximum number ofmultiple-use numbers valid at any one time can be determined by the cardissuer but would be preferably in the range of 5-10. In the case of anyattempted use outside the allocated range, the next multiple-use numbercan be used as an additional identifier to validate the transaction. Inthis case, only a subset of the digits should be given by the user toprevent a fraudulent trader being able to gain access to multiple unusedmultiple-use numbers. As soon as a single use number is disabled (step320) on use (step 318), an additional number from the “issued not valid”list for that customer is allocated to the “issued and valid” list,ensuring a continual supply of multiple-use numbers up to the maximumallowed until the next set of multiple-use numbers are issued. (Step322).

In relation to the actual supply of the additional credit card numbers,this will not cause any difficulties to the credit card provider. Forexample, with a standard master credit card number, there are up tofifteen or more digits, the first of which is used to identify thecredit card provider, e.g., American Express®, VISA®, Mastercard®, etc.For major banks, three digits are used to identify the issuing bank. Thelast digit in a typical sixteen digit master credit card number is achecksum used to confirm that the number is a valid number. This leavesa total of up to 11 digits or more for the account identifying numberand the expiration date. In some instances, the expiration date may notbe sent back for clearance, while with certain credit card providers,additional credit card numbers or even additional information isrequired for clearance. For example, certain credit card providers printadditional numbers on the card, which additional numbers are notembossed on the card and do not form part of the master credit cardnumber. These additional printed and non-embossed credit card numberscan be used to identify that the person proffering the card for anon-present card transaction is actually in possession of the card whenthe order is made whether it be in writing or by phone. There are manydevices, digits, pieces of information, etc. used by a credit cardissuer or processor working for a credit card issuer to clear the creditcard for the specific transaction. According to another embodiment, whenissuing additional credit card numbers in accordance with the presentinvention, such additional credit card numbers could include a codewhich would identify that the person using the additional credit cardnumber in a remote transaction is the one to whom the numbers were sentor, in the case of a disposable credit card, is the one to whom thedisposable credit card was sent.

A preferred feature of these additional credit card numbers is that theybe constrained to be in the correct format for a credit card number witha valid check sum, while at the same time be mathematically unrelated toeach other or to the master credit card. In certain situations, forsingle use numbers, the expiration date is virtually irrelevant. Thus,using the month code of the expiration date with said eleven digits,there are 12×10¹¹, i.e., 1.2×10¹², i.e., 1,200 billion possible uniquecodes available for any given credit card provider. This would allow for50 transactions a month for 10 years for 200 million account holders,before any codes would have to be recycled or a new header codeintroduced. When it is understood that there are then another 10⁴ headernumbers that a credit card provider can use, it will be appreciated thatthe structure and arrangement of existing master credit card numbers issufficient to operate this invention with the advantage that theexisting infrastructure of dealing with credit card transactions can beused with minimum modification. All that is required for the credit cardprovider is to store the generated numbers against the master creditcard number or other type of account number.

If, for example, the card is a VISA® card, there are approximately21,000 issuing banks. The sixteen digit number has a “4” followed by afive digit code to identify the card issuer. The last number is achecksum to verify that it is a valid number. As a result, there are21,000×10⁹×12 (252 trillion) unique numbers and associated expirymonths. This number of codes is sufficient for 36,000 years oftransaction processing at the current annual rate of approximately 7billion transactions per year.

While existing credit card formats allow for a sufficiently large numberof available card numbers, numbers will eventually need to be recycledfor allocation. As the range of available numbers reduces in size overtime, additional or recycled numbers should be added back into thisrange to ensure that the allocation process is performed from a rangesufficiently large to maintain random allocation. The length of timeprior to recycling depends on the total number of available unique cardcodes available to an issuer and the number of transactions that uselimited use numbers. Such recycling can only occur after a number hasbeen invalidated for further use and is no longer valid for refunds.Once recycled, automatic fraud detection mechanisms that would normallybe activated on the attempted reuse of a previously inactivated cardneed to be altered by removing the recycled number from the list ofpreviously issued limited use numbers.

2.3 Limitations on the Use of the Credit Card Numbers

The use triggered condition subsequent limitations placed on limited usecard numbers, i.e., transaction value limitations, number oftransactions limits, etc., are central to their additional flexibilityand security compared to conventional credit/debit/charge cards. Theselimitations can be imposed and controlled in a variety of ways. Forexample, the limitations can be stored within a database held by thecard issuer and used to check that the transaction falls within theselimitations during the authorization process.

FIG. 4 is a flow chart illustrating an exemplary process for limitingthe use of a credit card number. A CPU can allocate a credit card numberto a master credit card number (step 402), and allocate a condition tothe credit card number. (Step 404). The CPU can then store the conditionin a database of conditions. (Step 406). These limitations can beassigned by the issuer in a predetermined manner or can be imposedaccording to the requests of the card holder. These limitations can beencoded with the limited use numbers when the numbers are issued to auser so that the user can determine the limitations associated with aparticular card. These limitations can be altered once a number isissued by updating the issuer database and the user maintained list ofnumbers. Communication between the user and card issuer to make thesechanges can be posted, conveyed verbally or electronically. (Step 408).When the card is used for a transaction (step 410), the transactiondetails are compared by the processing software with the limitations andthe transaction is authorized only if the transaction falls within theselimitations. (Step 412). Alternatively, the limitations can be encodedwithin part of the number format that is transmitted during atransaction. The limitations would then be decoded from the transmittedtransaction details by the card processor. This would offer the usermore control, but would offer less security since knowledge of theencoding format could be used to fraudulently alter the limitationschosen by altering the appropriate portion of the limited use numberformat.

As Internet commerce develops, there will be an increased need for awide range of financial transactions. The limitations placed on limiteduse card numbers can be used to implement a wide range of paymentoptions. For example, a credit card number can be limited to a singletransaction for a pre-arranged transaction limit. Alternatively, acredit card number can be used, for example, to implement an installmentplan where the credit card number is, for example, only valid for twelvepayments for a pre-arranged transaction limit for twelve months to asingle merchant. This plan provides security against fraud because it islocked to a single merchant, and it is only good for one year.Similarly, a credit card number can be used to implement a debit planwhere the credit card number is limited to a specific merchant.

When the limited use number is limited to a specific merchant, themerchant can be prearranged by the user or can be determined by firstuse. In this situation a limited use card can be used to generate anaccount specific to a single merchant. For example, this can be used insituations on the Internet where a web merchant will retain a creditcard number for later purchases. By being limited to a single merchant,theft of the number from the merchant's computer systems will not allowthe card to be used elsewhere. Also, any such use will immediatelyidentify a specific merchant as having suffered a security breach.Determination-by-first use could involve linking the merchant name orcredit card system identification number at the time of making thepurchase, during the authorization process or during the settlementprocess.

Finally, a credit card number can be used as a gift voucher where thecredit card number is limited to a specific transaction value or limit,but it can be used for any merchant. A gift voucher limited use cardcould also have a pre-determined limitation to a specific merchant or atype of merchants or to a group of merchants such as within an “onlineshopping mall”.

2.4 Distribution of the Credit Card Numbers

The next matter that is considered is how these additional credit cardnumbers and/or additional credit cards are distributed to a credit cardholder. One way of providing such additional credit card numbers and/oradditional credit cards is to in some way provide them physically to themaster credit card holder, whether it be by collection, delivery bycourier, post or some other way which can generally be covered under theheading of provision by post. Obviously, the financial institutions wishto provide the additional credit card numbers or the additional creditcards to the user as efficiently as possible with the minimum risk ofthe additional credit card numbers and/or cards falling into a thirdparty's hand. While one can never prevent theft, for example, of acredit card from a user, what is important is to ensure that thesedisposable credit cards and/or credit card numbers are delivered to theuser with the least possibility of a third party obtaining either thenumbers or the disposable credit cards from the time they are generateduntil the time they are physically received by the user.

It is envisaged that there are various methods by which a credit cardprovider could issue the additional credit card numbers and/or creditcards to the user. One of the simplest ways would be to post them onrequest. Another way would be for the credit card provider, afterreceiving a payment of an account or with a statement of an account, toprovide a sufficient number of additional credit card numbers and/oradditional credit cards to replace the ones used since the previousstatement. Particularly, if such statements do not quote the mastercredit card number or some code number, it would be possible to put inadditional checks on the activation of the additional credit cardnumbers or credit cards. Some form of receipt system could be used. Inthis way effective theft would be reduced.

FIG. 5 is a flowchart illustrating an exemplary process for distributingcredit card numbers. A credit card issuer allocates a master credit cardnumber or more generically a type of master account number to a mastercredit card or account owner. (Step 502). The credit card issuer thenallocates limited use numbers to the master account number. (Step 504).For pre-prepared cards, the card issuer can decide whether to print (orincorporate by some other means such as embossing) one number per cardor multiple numbers per card. (Step 506). The card issuer can distributemultiple numbers using a single card (step 508) or distribute multiplenumbers using multiple cards. (Step 512).

In either case, it is important that the user can keep track of whichnumbers have been used. If the card has only one number, an opaqueremovable cover can be used to cover one or more portions of the card.(Step 510). For example, the opaque removable cover can cover the numberportion of the card, so that the cover has to be removed before the cardcan be used. The act of removing the cover indicates that the cardnumber has been accessed or used.

Alternatively, an opaque removable cover can conceal a message such as“used”. The opaque removable cover can be a scratch off layer that isscratched off before or after the card is used. The scratch off layercan resemble the layer that is often used to cover lottery numbers orthe like. Or alternatively, the single use cards can be placed in aself-contained container that resembles a razor blade dispenser. (Step516). The owner can remove a single use card from a first compartmentand then place the used card into a second compartment.

If the card has multiple numbers, the owner can keep track of thenumbers by using a device that covers one or more portions of the card.(Step 510). The device can cover the numbers until they are used. Asdescribed above, the device can comprise multiple opaque layers thatmust be removed prior to the use of each number. Alternatively, eachnumber could be visible when the card is issued and each number isassociated with a panel in which an opaque covering conceals a messagethat indicates that the number has been used. After each use, thecorresponding covering is removed or scratched off to indicate that thenumber has been used.

In both above cases the solutions incorporated on the cards act toremind the user which numbers have been used. The critical check on thevalidity of the number is performed by the processing softwareresponsible for authorizing card transactions.

The additional credit card numbers and/or cards can be sent with astatement. (Step 518). The additional credit card numbers are notactivated until the statement is paid. (Step 520). The card issuer couldalso require that the payment be accompanied by the master credit cardnumber or another identifier. Or, for example, an additional securitystep involving either direct contact with the issuing credit cardcompany or an independently issued password to allow activation of anelectronic device could be used.

A further way in which the additional credit card numbers and/oradditional credit cards could be distributed to the user is by way of anATM machine. (Step 522). The ATM machine with very little modificationcould provide the additional credit card numbers. Similarly, withrelatively little modification, an ATM machine could provide additionalcredit cards.

Cards/single use numbers can be issued directly into an electronicdevice that is capable of storing such numbers. This applies to mobilephones and pager devices to which information can be transmitted usingexisting systems and computers connected either directly or via atelecommunications system to the Internet or a specific host computersystem. In such a situation a mechanism is required to protect thesenumbers in transit to prevent unauthorized access. For globalapplications, this mechanism must not be subject to export restrictions.In addition, this protection should not be susceptible to “brute force”decryption techniques. Such a system is described below in relation tothe storage of single use cards.

An alternative method to provide additional credit card numbers could beby way of a computer programs. Obviously it would be necessary for thecredit card provider to have sufficient security that when the computerprogram was dispatched, either through the telecommunications network orthrough the post, that unauthorized access could not be obtained.

2.5 Electronic Use of the Credit Card Numbers

In the situation where the user stores and accesses limited use numbersvia an electronic device such a computer of any form (desktop,television or cable linked Internet access device, laptop, palmtop,personal organizer, etc), any device that can deliver the same functionsas a computer or dedicated Internet access device, a dedicatedmicroprocessor device with key pad and screen or any form of telephonewith associated microprocessor controlled electronics, the associatedsoftware can perform some or all of the following functions:

1) Password controlled access to software or other security activationsystem that can verify that the user has a valid right of access.

2) Secure storage of issued limited use credit/debit/charge card numbersuntil required by the user. These numbers can be stored in a variety ofencrypted forms. An additional security step is to encrypt the number inthe form a valid credit card number as previously described.

3) Secure storage of transaction details and date of use forreconciliation with records held by the credit/debit/charge card companyin case of disagreement. This may include digitally signing eachtransaction record.

4) Facility for user to review past usage of limited use card numbersand transactions.

5) Notification to user of available number of limited use cards.

6) Initiate automated request from software to card issuing organizationor agreed agent for further cards to be issued by previously agreedroute if requested by user or if the number of available limited usecards is less than a pre-arranged limit.

7) Secure communication between software package and card issuingorganization or agreed agent for downloading additional limited usenumbers. This secure communication can exploit any available form ofencryption suitable for this purpose.

8) Secure communication between card issuing organization or agreedagent and the software package for the transmission of informationregarding credit card transactions, account balances and otherinformation as requested by the user or card issuer. This securecommunication can exploit any available form of encryption suitable forthis purpose.

9) Automated or manual means for transfer of credit card information tothe merchant. The software can integrate with Internet software in thesituation where it is run on a device linked to the Internet or similarelectronic network and allow automatic transmission of transactiondetails if the merchant software so allows. To ensure compatibility withany form of merchant software the user also has the option of draggingand dropping a limited use number displayed by the software onto theappropriate part of a web page, or manually entering the number. In thecase a device intended for use over the telephone, the number can eitherbe spoken by the user or appropriate tones can be generated toautomatically transmit the number to the merchant.

10) Use of digital signature verification to verify both parties of acredit card transaction (i.e. merchant and cardholder).

11) Use of digital signature verification to verify both parties of acommunication involving the transmission of financial information oradditional limited use card numbers (i.e. card issuer and cardholder).

12) Use of stored lists of limited use numbers held by user and cardissuer as dynamic passwords to verify both parties (user and cardissuer) of a communication involving transmission of financialinformation or additional limited card numbers.

For “card not present” transactions, it is proposed that the customeruses an electronic device to store issued single use numbers. This mayrepresent a range of devices from a mobile telephone, pager, dedicatedsingle use storage device or a software package that can run on range ofplatforms such as a conventional desktop computer, television basedInternet access device (e.g., WebTV) or a portable computing device.

The software that is used within these devices for storing and accessingthese numbers will have specific features that are common to allplatforms/devices.

For security reasons, access to the software will be password protectedor protected by another security system that allows identification ofthe user (e.g., magnetic stripe card reader, chip card reader,electronic token generator, fingerprint recognition system or the like).Multiple passwords may be employed to provide limited access to certainindividuals, for example limiting access for a family member to singleuse numbers with specific pre-allocated limits on application or maximumtransaction value.

The single use numbers are preferably stored in a secure form involvingone or more encryption systems. It is proposed that a dual system willbe employed using a standard protocol (e.g., DES or RSA encryption) anda specific system designed for credit cards as described below.

“Brute force” decryption involves using multiple fast computers andspecific algorithms to test large numbers of possible encryption “keys.”Success can be determined by seeing whether the result appears in theexpected format, for example as comprehensible English text in the caseof an encrypted document. If the encrypted version is in an identicalformat to the unencrypted version (though with different information)then brute force decryption cannot succeed. This is not acomputationally viable option for text but it is possible for creditcards.

The approach is to break down each component of a credit card number andencrypt these with a private password so as to maintain the numericalcomposition of each component. The end result should be securelyencrypted but should not represent another existing credit card account.This can be achieved by constraining the encryption system to convertthe credit card header sequence used to identify the issuing bank(usually 4-6 digits) into a currently unused sequence. Since thisinformation will be constant for all cards from the same issuer, thisinformation should be randomized (rather than encrypted) to preventrecognition of a valid decryption solution. Once the rest of the numberis decrypted by the program, the appropriate header sequence can beadded. The remaining digits excluding the checksum (the last digit) arethen encrypted using any private key encryption system that willmaintain the same number of digits and produce a result that representsthe numerals 0 to 9. The expiration date and any other identifyingdigits are also encrypted in such a manner as to respect their existingstructure, i.e., the month is encrypted between 1 and 12 and the year isencrypted so as to represent a number within the next three years thatensures that the expiration date is valid. Following these steps, thedigits used to calculate the checksum in a normal card number areprocessed to calculate a valid checksum for the encrypted card. Theresult is a valid appearing credit card number that has a valid checksumand which can be guaranteed not to belong to any existing credit/debitcard account holder.

For example, for a card with a 6 digit header and valid checksum, e.g.,“1234 5678 9012 3452 expiration date of 12/99,” 123456 is randomlyassigned to a currently unused header sequence, e.g., 090234 (this is anexample and does not necessarily represent an unused header sequence).789012345 is encrypted into another 9 digit number, e.g., 209476391.12/99 is encrypted to a valid date format that ensures the card is notexpired, e.g., 3/00. The checksum is recalculated to produce a validappearing credit card number, for this example the checksum is 4, i.e.,0902 3420 9476 3914 expiry 3/00.

To decrypt this number for use or after transmission from the bank, theappropriate header sequence for the issuer is exchanged for the digitsin the encrypted number. The other digits are decrypted using theprivate password and the check-sum is recalculated.

Provided that the header number is unused and the private passwordremains private, then this number is encrypted in such a way that bruteforce encryption cannot be used to determine the original number, sinceit will not be possible to determine when the correct solution has beenreached. In combination with standard encryption systems, this allows ameans to securely store credit cards and transmit them over insecuresystems with confidence.

Once the appropriate password is entered into the software, the nextavailable single use number is decrypted and either displayed, allowingthe customer to use it in any form of trade that can achieved by quotingcredit card information, or directly transmitted via the software to themerchant. Once used, the single use number is removed from the storedlist. The date of access, the number accessed and any additionalavailable transaction details are then stored in a secure fashion anddigitally signed to allow for verification in the case of a disputedtransaction. Each access to a single use number requires the entry of apassword to prevent unauthorized access if the customer leaves hissoftware/computer device unattended and active.

Other types of encryption may also be used, for example, which requirethe use of a mask and/or private key. For example, as described above,this approach also breaks down and encrypts each component of a creditcard number so as to maintain the numerical composition of eachcomponent. Similar to that described above, the bank identifying headersequence, e.g., in the case of VISA® cards, the initial digit “4”followed by the 5 digit BIN number, is replaced with an equal number ofrandom digits taken from the range of unused headers. This ensures thatthe resulting number does not represent some other valid existing creditcard number. These replacement header sequence digits can be fixed for agiven card issuer and can be reconstructed after decryption.

The final checksum digit can be handled in one of several ways. Forexample, the checksum digit can be recalculated based on the encryptedremaining digits as described above. Alternatively, the final checksumdigit can be omitted from the encryption process and recalculated afterdecryption.

The remaining digits can be reformatted into another number with thesame number of digits by any reversible encryption process. The sameprocess may also be applied to all other numerical informationtransmitted that may be issued during a transaction, e.g., the expirydate and other codes. One process for randomizing these remaining digitsis described above. Another process to encode the remaining digits is toperform a digit by digit mathematical operation in combination with amask containing the same number of digits as the remaining digits to beencoded.

For example, assume the original remaining digits are 878918982 and therandom mask digits, containing the same number of digits as theremaining digits to be encoded, are 143337658. A modulo 10 arithmeticfunction is then performed using the original remaining digits and therandom mask digits as follows to achieve the encrypted result.

Original remaining digits 8 7 8 9 1 8 9 8 2 Random mask digits 1 4 3 3 37 6 5 8 Encrypted remaining digits 9 1 1 2 4 5 5 3 0

After transmission of the encrypted card number, including thereplacement header sequence digits, the encrypted remaining digits andthe checksum digit, if appropriate, the encrypted card number isseparated out into its components. The encrypted remaining digits aredecrypted in the opposite manner in which they were encrypted.Specifically, knowing the random mask digits and the encrypted remainingdigits, a modulo 10 subtraction is performed to reconstruct the originalremaining digits as follows.

Encrypted remaining digits 9 1 1 2 4 5 5 3 0 Random mask digits 1 4 3 33 7 6 5 8 Original remaining digits 8 7 8 9 1 8 9 8 2

Even with this simple encryption technique, the decryption solutionrequires access to the private key because the solution cannot beidentified in isolation. In addition, this process enables thereconstruction of one of the sequences, i.e., the original remainingdigits, the random mask digits or the encrypted remaining digits,knowing the two other sequences.

FIG. 6 is a flow chart illustrating an exemplary process forelectronically using credit card numbers. The software can be launchedeither on its own or activated by an icon integrated into an Internetbrowser. (Step 602). The software can provide a simple interface with agraphical appearance that exploits familiar images of credit cardsand/or ATM's. The software can be programmed using Java code or a Javacore embedded in a c/c⁺⁺ application or equivalent programming language.

Once launched the user puts in one password to gain access to the mainscreen of a computer, which contains a keypad to allow a PIN to beinputted either by keyboard or by mouse clicks. (Step 604). The latterprotects against any covert attempts to record passwords by trapping keystrokes. A consecutive number of errors in inputting the password willpermanently disable the program and overwrite remaining encryptednumbers. After the correct PIN is entered, the user can select a newlimited use number with or without additional constraints (e.g. maximaltransaction value). (Step 606). A new limited use number is thendisplayed on the graphical interface. The software can provide secureaccess to encrypted credit card numbers that are stored on a computer'shard disk. (Step 608). These numbers can be accessed for use on theInternet or for use over the phone/mail order. (Step 610). The numbersmust therefore be able to be inserted directly into a web page (step612), or printed out/copied from screen for use in other ways. (Step614). The limited use number can be copied, printed, pasted via theclipboard (or equivalent) or dragged-and-dropped onto a web page. Thelength of time a number is displayed and how the program terminates areuser configurable. The user can also record a comment to provide furtherinformation about how a number was to be applied. For automatedtransactions, the software should ideally be able to intercept andrespond to merchant server initiated signals activating integratedfunctions within the browser.

Once a number has been accessed, it can be deleted from the encryptedlists. (Step 616). The date, number, current URL in the case of Web useand any user comments are then stored by a separate form of encryptionto facilitate audit/review. (Step 618). The user can review, but notedit this information

There should be a facility for downloading additional numbers eitherfrom additional floppies or via the Internet using high securityprotocols. (Step 620). The latter function can be performed by aseparate program.

The program should include a maximal degree of transparent securityfeatures, i.e., features that do not affect a normal user, but thatprotect against the program being reinstalled or copied onto a secondmachine. This means that the encrypted limited use numbers should eitherbe stored within the executable file or stored in a file that alsostores encrypted copies of the machine specific information. (Step 622).This is required to ensure that the numbers can only be accessed on themachine on which the software was first installed. The data files shouldalso be stored as hidden system files.

Some users may wish to have the equivalent of an electronic wallet thatcan be de-installed from one computer and reinserted on another, forexample, when transferring a “wallet” from an office to a home machine.This transfer process ensures that only one version of the program isrunning at any one time and that no problems arise in terms ofreconciling lists of used numbers. Appropriate security mechanisms canbe implemented to identify the valid user.

Appropriate security measures include encryption. Encryption of limiteduse numbers should involve two levels as exemplified above. At the firstlevel, the card numbers are encrypted using an algorithm that acts onlyto alter the free digits within the credit card. The header sequence(i.e., BIN number) is left unaltered or converted into an unused BINnumber and the checksum recalculated. This prevents any form of brutedecryption because there will be no way of telling when the correctalgorithm has been selected since each number starts and ends up as avalid looking credit card number. Following this step each number isencrypted with industry standard encryption methods (e.g. RSA or DES).Following decryption within the program the checksum is recalculated forthe final number and the appropriate bin number reinserted.

The software can be shipped on a single 1.4 Mb Floppy (or any othercomputer readable or usable medium) in an encrypted form or downloadedfrom a website. Limited use numbers can be issued either with theprogram or independently. An independently shipped password can berequired for installation. The installation process will allow theprogram to be installed a restricted number of times after whichcritical data is overwritten. The precise number of allowableinstallations will be easily alterable within the software design. Onceinstalled on the host computer, the program encrypts internalinformation regarding the machine's configuration to protect againstcopying of the program onto other machines. At first installation theuser can select his own passwords. These will be used to control bothaccess to the programs and to influence the pattern of one level ofencryption that is applied to limited use numbers.

As numbers are accessed, a graphical indicator of the remaining amountof limited use numbers provides early warning if additional numbers arerequired. The software can also provide a log of previously accessednumbers, the date, associated URL if activated from within a browser andcomment; a summary of account expenditure; assistance with addingadditional numbers from disk or via Internet; the ability to configureadditional passwords/users for shared cards; and/or hot link Internetaccess to the card number issuer's web site.

2.6 Processing of Card Transactions

It is envisioned that additional credit card numbers and/or additionalcredit cards would be processed by merchants in the same manner asexisting credit card numbers and/or credit cards with the merchantobtaining validation of the credit card number from the credit cardcompany or authorized third party. In much the same way as at present,the additional credit card number would be matched to the customeraccount and the account would be debited accordingly. The merchantreimbursement following verification of an additional credit cardtransaction would be performed in the normal manner. A particularadvantage for the merchant is that since they are never in possession ofthe master credit card number or indeed, in many instances, of themaster credit card, they have no responsibility for security to themaster credit card holder. It is envisaged that where there areadditional credit cards used, it may not be preferable to take animprint of the credit card manually, as the imprint can be takenelectronically. Similarly, those processing the credit cards willprocess them in the same manner described heretofore.

Processing systems for handling limited use cards perform a number offunctions including some or all of the following:

1) Verify that the limited use number is valid.

2) Verify that the transaction falls within limitations placed on thespecific number.

3) In the case of a limited use number associated with another account,verify that transaction falls within limits acceptable for theassociated account.

4) Provide authorization to the merchant if valid and within thelimitations for specified number and associated account.

5) Permit later transactions to be charged to a limited use number thathas been invalidated for further authorizations only if the transactionis generated by the same merchant that obtained pre-authorization forthe same transaction.

6) Deny authorization if invalid or exceeding limitations on number orassociated account.

7) Activate fraud detection mechanisms if invalid number or on attemptto reuse an invalidated limited use number.

8) Invalidate limited use number for further authorizations/payments iflimitations on use are met or exceeded by a specific transaction.

9) Maintain list of invalidated numbers for reimbursement in the case ofreturned or faulty goods for a defined period.

10) Limited use numbers and transaction details logged and linked toassociated account.

11) Transmit records of limited use and other card transactions to theuser by post or e-mail.

12) Instigate payment to merchant for approved transactions.

13) Instigate reimbursement to account holder in case of a refund.

14) Invoice account holder for payment for charges incurred or arrangesettlement via another account.

Many of the procedures associated with limited use cards representfunctions already performed by the clearing systems. These existingfunctions include: adding new credit/debit card numbers to theprocessing databases; allowing these card numbers to be activatedfollowing a confirmatory call to the issuer by the customer; conferringa credit limit on a credit card number; and invalidating a credit cardnumber from further use and marking any further use as fraudulent. Thisoverlap represents part of the commercial value of the single useinvention, minimizing the required changes.

Once a limited use number enters the clearing system it can be handledin a normal fashion, e.g., by ensuring that it has not been reported asbeing stolen and that it represents a valid account number within thedatabase. If the transaction is within the credit limit of the customerand the transaction limit or restricted use limitations of the limiteduse number, it is authorized.

Several specific modifications should be made to the processing softwareto implement the features of limited use cards. For instance, validlimited use numbers are stored in a database of valid account numbersalong with other information specific to limited use numbers. Thisincludes sufficient information to identify the customer to whom it wasissued and any additional limitations placed upon the card in terms oftransaction value or category of merchant for which the card can beused.

Once authorized, the limited use number is invalidated deactivated so asto ensure that further authorization/charges cannot be made on thatnumber. To allow for authorization preceding request for settlement by asubstantial delay, for example in the context of a mail order purchasewhere a credit/debit card number may be authorized at the time of orderand charged only when the product ships, delayed settlement to the samemerchant must be allowed.

Once the number of transactions permitted for a limited use card isreached, the central card processing software invalidates the card. Dueto the time delay that can occur between authorization and a merchantrequest for settlement, improved security is achieved by linking theinvalidation process to authorization. Linking invalidation tosettlement facilitates pre-authorizations at the cost of increased riskof, for example, multiple use of a card number intended for limited use.Pre-authorizations can be used with authorization dependent invalidationas described above. In the case where a transaction is not authorizedbefore being accepted by a merchant, the invalidation process will occurwhen the transaction details are transmitted to the processor forsettlement. When no authorization is obtained for a limited use numberthe system will therefore still operate normally with an increased levelof risk for the issuer/merchant as is the case with an unauthorizedconventional card transaction.

Whenever the credit limit or validity of a customer's account changes,all currently valid limited use numbers are identified and theirassociated credit limit is altered to the lower of either theirallocated transaction or the existing credit limit. If the customeraccount is closed or declared delinquent, all valid single use numbersare handled in the same manner.

Whenever a limited use number is used, the next available single usenumber previously allocated to the same customer and issued to thecustomer is added to the database of valid account numbers.

When a transaction is charged to a limited use number, the transactiondetails and customer account details are stored together for auditpurposes and the value of the transaction is added to the customer'saccount for billing.

The software for storing transaction details and printing statements canbe modified to allow for both the customer's conventional accountdetails and the limited use number transaction details to be reported.

Processing of limited use numbers can be integrated into existingsystems in a variety of ways. The authorization and settlement processcan be completed in a single cycle or split into a separateauthorization and settlement processes as is commonly done in existingcredit card systems.

In the case of an entirely new, stand-alone, limited usecredit/debit/charge card processing system, the above functions can beimplemented without restriction in any suitable computer capable ofincorporating the required database and communication functions. Such asystem should be able to provide an authorization for a transactionwithin the same time scale as an existing credit/debit/charge cardtransaction.

In the case where the above functions have to be integrated intoexisting systems several approaches can be taken to minimize therequired changes. It is possible to add steps to the processing chainthat is encountered as soon as a credit/debit/charge card number isreceived from a merchant.

FIG. 7 is a flow chart illustrating an exemplary process for processinga transaction. In step 702, a software system receives transactiondetails from a merchant. The software system determines whether thenumber is a limited use number or a conventional card number. (Step704). If the number is a conventional card number, it is passed onunchanged into the processing system and can be handled by existingsystems with no modification. (Step 706). The merchant receivesauthorization from the system responsible for authorizing conventionalcard numbers. Merchant reimbursement is similarly unaffected. (Step708).

The system can check the limited use number and the correspondinglimitations. (Step 710). If the number is not valid for the designatedtransaction, the transaction is denied. (Step 712). Otherwise, adatabase look-up procedure determines the associated master accountnumber and transmits this number (i.e. the master account number) backinto the processing system. (Step 714). This allows all existing frauddetection, authorization and demographic software procedures to becompleted with no alteration. (Step 716). Once the master account numberis substituted for the limited use number a number of additional stepsare required. (Step 718). If the criteria for invalidating the limiteduse number have been met during this transaction, then the limited usenumber is invalidated for all future transactions except refunds. Anadditional limited use number can be automatically issued if a continualsupply of single use numbers is required. The transaction details andmaster account number are then transmitted for inclusion within adatabase to allow for tracking of transaction details and billing of theuser. These functions do not need to be performed before anauthorization is issued but can completed afterwards. (Step 720).However, performing such steps together with the validity verificationof the limited use number prior to issuing an authorization message to amerchant is a feasible option with a minor reduction on the processingtime required to issue an authorization message.

With the above system, the software responsible for substituting themaster account number for the limited use number can also processadditional features unique to limited use numbers. These featuresinclude transaction value limitations, merchant type restrictions andgeographical limitations. If the transaction exceeds the limitationsplaced on the limited use card then authorization is denied and themaster credit card need not be passed on for further processing. In thecase of a transaction falling within the limitations of a limited usecard, then the transaction details are passed on with the master accountnumber for conventional validation. In this way the restrictions inplace for the master account (e.g., available balance, expiry date) arechecked for each limited use transaction.

Specific fraud detection mechanisms can also be incorporated into thesoftware. For example, on the first occasion that an invalidated limiteduse number is used this transaction can be flagged as potentiallyfraudulent and appropriate measures taken. Repeated attempts toauthorize invalid numbers from a single merchant or group of merchantsalso potentially points to fraud and can lead to activation ofappropriate fraud management measures.

The above system requires the least modification of existing systems butmay take up to twice the processing time of a conventional transactiondue to the double authorization process, once within the limited useverification and translation step and once within the standard systems.It may be advantageous to initially process the limited use card as amaster credit card by using a single list of limited use numbers andmaster credit card numbers.

FIG. 8 is a flow chart illustrating another exemplary process forprocessing a transaction. In step 802, a software system receivestransaction details from a merchant. The software system has access to adatabase that contains additional information to identify the associatedaccount or means of settlement and specific limitations relating to theuse of limited use cards. As a result, limited use numbers can beassociated with existing accounts in the manner currently used toassociate multiple conventional accounts in the case of multiple cardsissued to a single company for corporate use. (Step 804). During anauthorization the associated account number need not be identifiedprovided each limited use account is updated whenever the status of theassociated account changes (e.g. available balance, account validityetc.). The system can deny authorization (step 806) or authorize atransaction (step 808) without identifying the associated accountnumber.

For settlement and billing purposes (step 812), the associated accountneeds to be identified (step 810), but this does not need to be doneduring the course of an authorization. The existing software should bemodified or linked to a new program that performs duties specific forlimited use card numbers as described above. (Steps 814, 816, and 818).These functions do not need to be performed before an authorization isissued. These functions can be completed afterwards.

This system requires more modification of the existing processingsoftware systems, but offers authorization times within the sametimescale as existing transactions since only one authorization steps isinvolved. Other activities such as updating the limitations on thelimited use card when the master account changes can be performedoutside the authorization process (i.e., “off-line”).

Such other activities can also take place while the system is operating.The system may include some or all of the following features:

1) A system capable of altering the nature and value of limitationsassociated with a specific limited use credit/debit/charge card numberon the basis of the usage of that specific limited use card number intransactions, where such alteration is conducted while the system isoperational;

2) A system capable of altering the nature and value of limitationsassociated with a specific limited use credit/debit/charge card numberon the basis of instructions generating on behalf of the issuing bank,where such alteration is conducted while the system is operational; and

3) A system capable of altering the nature and value of limitationassociated with a specific limited use credit/debit/charge card numberon the basis of instructions generated on behalf of the card holder,where such alteration is conducted while the system is operational.

The invention is not limited to the embodiments hereinbefore describedbut may be varied in both construction and detail. For instance, theinvention has been heretofore described mainly in the context of asystem in which a customer receiving a single use card already has amain account with the credit card provider. But this need not be so. Forexample, it is envisaged that an ATM machine (or similar apparatus)could be used by people who did not have a credit card account topurchase disposable credit cards, which disposable credit cards couldthen be used for either card present or remote transactions. When thecard had been used, the card would be simply reinserted into the ATMmachine, and after a suitable period of time the purchaser's accountwould be credited with any money not spent. Similarly, if the person whopurchases the disposable credit card does not have an account of anysort with the credit card provider, the credit card could still bepurchased from the ATM machine and then any refund could take place asufficient time after the transaction would have been cleared, whichrefund could be either in the form of a cash refund to the purchaser orto a crediting of that purchaser account with another financialinstitution. Similarly, it will be appreciated that the use of an ATMmachine is not essential, as the disposable credit cards or single usecredit cards could be purchased in the normal way in which one purchasesany other goods or services, such as either directly in a face-to-facetransaction or by post.

Similarly, while in the above it has been suggested that there could besingle use credit cards that would be purchased, there is no reason whythey could not be multiple transaction credit cards with an aggregatecredit limit. Further, these cards could, instead of being credit cards,be simply credit card numbers for single or multiple use. It is,however, envisaged that for operational efficiency, these numbers aremuch more likely to be issued as disposable credit cards or single usecredit cards. Thus, for those who do not wish to handle a credit card orwhose credit worthiness is such that they would not be allowed to have acredit card, it will now be possible for them to have the use of acredit card. This would have considerable advantages for the credit cardproviders.

2.7 Card Holder Controlled Validity of Credit Card Numbers

In processing a transaction as described above, one step is to determinewhether or not a limited use credit/debit/charge card number is valid.As discussed above, when a new credit card is presently issued, it iscommonly required that the card holder activate the card. Specifically,the card holder may be required to communicate with the credit cardissuer to activate the card before it can be used. Alternatively, in oneembodiment of the present system, the card holder can control theactivation or validity of a credit card number, or equivalenttransaction code, during the course a transaction. Thus, in thisembodiment, the card holder has the control, security and confidencethat payments can only be made with his or her express permission.

FIG. 9 is a flow chart illustrating an exemplary method of controllingthe validity of a limited use credit card number. The card holder has acredit card number, or equivalent transaction code, that is allocated tothe card holder, but is not yet active. (Step 902). The card holder canacknowledge delivery of the credit card number, but the number remainsinactive within the card issuer's processing system, e.g., a bank'sprocessing system. (Step 904). When the card holder wishes to conduct atransaction, he or she contacts the card issuer to activate the creditcard number. (Step 906). Activating the credit card number before everytransaction is cumbersome, but in the context of a remote transactionfor example, via the Internet or equivalent network, the communicationbetween the card holder and the card issuer can be achieved very rapidlyby an entirely automated system that will activate the card during theprocess of conducting a transaction with an Internet based merchant. Thecredit card number is activated for a specific transaction only whenspecifically requested by the card holder. (Step 908).

The properties of this validation or activation process can vary. Forexample, the validation could be for a specific time period, for aspecific merchant or group of merchants, for a specific type oftransaction, or for a specific number of transactions (authorizationsand/or presentments). These properties can also be combined in anypermutation. For example, a card holder could request that his or hercredit card number be validated for one transaction with a specificmerchant up to a specific value limit or value range (e.g., a specificvalue +/− a configurable range). In the event that no authorization isreceived within a defined period, the validity can lapse. Thiscombination provides a solution that meets the need for a secure,flexible payment system for remote transactions.

More specifically, for Internet transactions the card holder wouldreceive a software package from the card issuer along with a uniquepersonal validity limited credit card number. This software packagewould also facilitate completion of the merchants web page using ECML(electronic commerce modeling language) or some other equivalentelectronic wallet system. Merchants wishing to use this system provide aunique merchant identification number on their web site. For merchantswho are not compliant with such systems, a simpler automated method,e.g., “drag and drop,” of transferring card number and other details issupported.

When a card holder wants to conduct a transaction, he or she activatesthe validity limited credit card software using a password or hardwarebased user identification system (e.g., magnetic stripe card reader,chip card reader, electronic token generator, fingerprint recognitionsystem or the like) thereby identifying himself or herself with the cardissuer. The card holder then requests his or her credit card number tobe validated for the merchant as identified by the merchantidentification number. After use the card number is automaticallyinactivated again. The card holder may also specify additionallimitations as discussed above, such as value limitations and maximumnumber of available transactions. Alternatively, these limitations couldcarry default limitations, for example single transactions up to a valueof $100.00. This request would be transmitted via the Internet to thecard issuer's card computer processing system. The processing systemwould validate the card holder's password (or hardware device), ifappropriate, and forward the appropriate validity request to the cardprocessing systems database.

The card issuer's server may also verify the merchant's identity byproviding confirmation of the merchant's name as it will appear on thecard holder's credit card statement. This merchant verification helps toavoid a common source of potential confusion for card holders in creditcard transactions. The merchant identification number can either be theactual credit card systems merchant-ID or another unique code. In eithercase, the credit card merchant-ID that will be transmitted to theprocessing system during the transaction is entered into the processingsystem's database. This ensures that only the intended merchant caninitiate a transaction with the validated credit card number. In theevent that a merchant identification code does not satisfy the cardholder's expectations, the card holder has the option to cancel thetransaction before any information is passed to the merchant's web site.

When application of the one or more limitations are confirmed, generallywithin a matter of seconds, the card holder is given verification ofsuch and is allowed to transfer the credit card number and transactiondetails to the merchant's web site. Since the merchant identificationnumber is used to validate a specific number of transactions for thatmerchant, there is no benefit of a rogue or fraudulent merchant tryingto steal the identity of another valid merchant. The transaction canonly be reimbursed to the merchant identified to the card holder by thecard issuer's system.

When a merchant receives the card holder's credit card number, themerchant processes this in an identical manner to an existingtransaction in known systems. The transaction is passed through to thecard issuer's processing system via the merchant acquiring and creditcard networks. At the card issuer's processing system, the transactionis handled by an authorization system that allows a card number to haveassociated validity restrictions or limitations, such as merchant-ID.If, in response to an authorization request, the authorization systemindicates a valid card number, with an appropriate merchant-IDvalidation and sufficient funds, a normal authorization response isreturned to the merchant. The number is then deactivated by the usetriggered processing software within the authorization system or the incase of a multiple outstanding transactions the properties of the cardnumber are updated to remove the permission for the authorizedtransaction (e.g. decrement the cumulated value limit). If theauthorization system identifies a problem with the request, for example,exceeding a limitation, the merchant is denied authorization.Transaction settlements and card holder billing proceed as describedabove.

In the situation where a card holder is making multiple purchases withthe same merchant within a short period of time, each validation by thecard holder may be cumulative so that all the requested transactions canproceed. For example, if the card holder requests two transactions, oneof $50.00 and one of $100.00 dollars for a specific merchant, the creditcard number will be validated for two transactions to that merchant witha cumulative limit of $150. This means that both transactions will beauthorized. In this case, the sequence of authorization requests fromthe merchant may differ from original sequence of validation requestsfrom the card holder.

This system may be implemented using the Internet card software package,or RAD software package, as described herein.

In general, the system provides a method for numbers and accounts to beset up and issued directly to the user. In addition, the system alsopermits users to directly alter the properties of a credit card accountwithin an issuer's authorization and settlement system. The set-up(issuance) and use of a limited use credit card number can take place atthe same time, i.e., in the same interaction or at separate times, i.e.,setting up (issuing) a limited use credit card number at one time andconfiguring the limited use credit card number at a later time.

This system has a number of advantages over existing credit cardsystems. Card fraud is greatly reduced since a stolen number requiresthe card holder to validate the card number before any transaction canbe completed. This protects against either interception of the numberduring a transaction or the number being accessed from a merchant'scomputer systems at a later date. In addition, if the number isauthorized, the merchant is assured that the card issuer has directlyvalidated that the card holder has requested the transaction. Thisprevents or limits a card holder's ability to repudiate the transaction.Moreover, the card holder has additional control on the purchasing powerof his or her credit card. The card holder has the reassurance thatpayment can only be made to the merchant described by the card issuingbank/organization.

2.8 Additional Uses of the Credit Card Numbers

In situations where the card-holder and card issuer are in communicationand authentication is required of one or both parties, the list oflimited use card numbers held by each party can used as a form ofidentification. In the manner of a dynamic password all or part of asingle limited use number a sequence of such numbers could be used toidentify either party without the need for issuing any additionalsecurity systems. Because this identification does not need to behandled by conventional transaction systems, all or part of a limiteduse number can be used for this purpose.

FIG. 10 is a flowchart illustrating an exemplary process for using acredit card number as a PIN number. In step 1002, a card issuergenerates a database of available credit card numbers. The card issuerselects a master credit card number or more generically master accountnumber (step 1004) and distributes the master account number to a masteraccount number owner. (Step 1006). The card issuer then allocatesadditional credit card numbers to the master account number (step 1008),and distributes the additional credit numbers to the master accountnumber owner. (Step 1010). When the master credit card number ownerneeds or desires to access account information (step 1012), the masteraccount owner can use one of the additional credit card numbers as a PINnumber. (Step 1014).

As can be readily seen, there are fundamental differences between thesystem of the present invention and any system that uses a PIN or othernumber (whether constant or varying from transaction to transaction) tovalidate a transaction. In the present system the numerical detailsconveyed in the course of a transaction are identical in format to anexisting credit card number but no unique account code is included. Thismaximizes the security and privacy of a credit/debit/charge cardtransaction. Within the processing system the validity of the limiteduse number is verified first and then the associated account identifiedsecond by examining information stored with the limited use number. Withthe transmission of an additional PIN or other number in addition to theaccount number or other unique identifier, there is a lower level ofsecurity and privacy. Within any form of PIN identification (and asdescribed by Rahman) the associated account is identified first and thenthe PIN verified after this step. For this reason many card holders canshare the same PIN, indeed in most cases due to the short length of PINcodes many users do have identical PINs but different account numbers.For our system each limited use number must be unique at the time of useand so the associated account can be uniquely identified.

2.9 System Locations

With reference back to FIG. 1, and as described above, centralprocessing system 100 can internally perform the approval and denial ofcredit card transactions or this function can be delegated to a separateclearance processing facility. In other words, central processing systemcan be located within the card issuer's main processing system or at astand-alone facility. In an exemplary embodiment of the presentinvention, central processing system 100 adds additional functionalityto existing credit/charge/debit card systems without any, or withminimal, alterations. In general, central processing system 100transmits certain transaction details in a bi-directional manner, i.e.,utilizing dual interfaces between central processing system 100 and themerchant and between central processing system 100 and the card issuer,without revealing the master credit card number to the merchant. Thedual interface transmissions, referred to herein as remapping, allowmerchants and card issuers to handle transaction details in the samemanner as conventional credit card transactions. Such conventionalcredit card transactions may be, for example, authorizations,settlements, copy requests, and charge-backs.

Remapping can be implemented by utilizing database look-up functionsusing existing industry-standard computer platforms. In addition,remapping may occur by replacing the limited use card number with themaster account number.

FIG. 11 is a block diagram illustrating a credit card system 1100 inwhich a central processing system 1106 in accordance with an embodimentof the present invention is located within a card issuing bank's mainprocessing system 1114. The system 1100 includes merchant acquirers 1102connected to card issuing bank's main processing system 1114 via acredit card network 1104 and a switch 1116. The credit card network 1104may be any type of communication network, such as the Internet, a radionetwork, etc. as described above. A switch 1116 includes hardware andsoftware components. The switch 1116 may be configured to directincoming transaction details on the basis of the card number and todirect outgoing transaction details on the basis of the merchantacquirer identification number (referred to herein as the “merchantID”). The issuing bank's main processing system 1114 includes an issuingbank processing facility 1112 and a central processing system 1106. Thecentral processing system 1106 includes an acquirer interface 1108 and aSTIP interface 1110 for example.

Exemplary transactions will now be described with reference to FIGS. 11and 12. FIG. 12 is a flow chart illustrating an exemplary method ofconducting a limited use credit card number transaction. A userinitiates a transaction by presenting a limited use credit/charge/debitcard number, either in person or remotely as discussed above. (Step1202). A merchant acquirer 1102 routes this limited use credit cardnumber to the central processing system 1106 via the network 1104 andthe switch 1116. (Step 1204). This routing is done on the basis of aspecific bank identification number (referred to herein as “BIN”) whichis the first few digits of the limited use credit card number, asdiscussed above. In this example, the central processing system 1106acts as a stand-in processor.

If the limited use credit card number is invalid, or if the limited usecondition has been satisfied, i.e., the condition has been met orexceeded, step 1206, the central processing system 1106 will transmit asignal to merchant acquirer 1102 denying authorization of the cardnumber via switch 1116 and network 1104. (Step 1208). If the limited usecredit card number is valid, and if the limited use condition has notbeen satisfied, the central processing system 1106 transmits a signal tothe issuing processing facility 1112 via the merchant acquirer interface1108 and the switch 1116. (Step 1210). This signal includes the originaltransaction details but the card number and the merchant ID areremapped. This remapping provides the master credit card BIN number sothe signal will be routed to processing facility 1112. This ensures thatthe authorization can be obtained against the master credit card andthat any resulting authorization, or denial thereof, is returned tocentral processing system 1116, as this appears to the processingfacility 1112 to be the merchant. (Steps 1212 and 1214). Theauthorization, or denial of authorization, is the remapped within thecentral processing system 1106 to the original limited use credit cardnumber and merchant ID. (Step 1216). The central processing system 1106then transmits a signal to the merchant 1102 authorizing the limited usecredit card number, or denying authorization as appropriate, along withthe original transaction details via the switch 1116 and the network1104. (Step 1218).

FIG. 13 is a flow chart illustrating an exemplary method of conducting asettlement transaction. In a settlement transaction, the merchant 1102transmits a signal to the central processing system 1106 via the network1104 and the switch 1116 according to the BIN of the limited use cardnumber. (Step 1302). The central processing system 1106 remaps thelimited use credit card number with the master credit card or accountnumber, the merchant ID with a central processing system ID and themerchant text description with a central processing text description(step 1304), and transmits this remapped information to issuerprocessing facility 1112 via switch 1116. (Step 1306.) The processingfacility 1112 settles the transaction by payment, if appropriate, to thecentral processing system 1106. (Step 1308). The central processingsystem 1106 then remaps the master credit card or account number back tothe original limited use credit card number, the central processing IDback to the merchant ID and the central processing text description backto the merchant text description, (step 1310) and transmits thisinformation along with the payment, if appropriate, to the merchantacquirer 1102 via the switch 1116 and the network 1104 (step 1312). Aswith the authorization cycle, this settlement cycle ensures thatsettlement is obtained against the master credit card; that the cardholder's billing statement reflects the limited use transaction, withthe central processing ID, and that the payment for settlement isconducted through the central processing system 1106.

If a card holder challenges or questions a specific charge on his or herbilling statement, the copy request or charge back will be routed to thecentral processing system 1106, as this is the ID associated with thetransaction. In a similar manner to that described above, the centralprocessing system 1106 will remap the copy request or charge backaccording to the merchant ID and the limited use credit card number andtransmit the copy request or the charge back to the merchant 1102 viathe switch 1116 and the network 1104. The merchant 1102 transmits therequested copy or the charge back confirmation to the central processingsystem 1106 via the network 1104 and the switch 1116 according to theBIN of the limited use card number. The central processing system 1106then remaps the ID and card number information and forwards therequested copy or charge back information to the processing facility1112 via the switch 1116.

The system 1100 is advantageous in that it reduces communication delaysand fees but it requires the addition of the switch 1116. Alternatively,FIG. 14 illustrates central processing system 1406 as a stand alonefacility. The authorization, settlement, copy request and charge backtransactions described above are equally applicable to FIG. 14, exceptswitch 1116 in FIG. 11 is no longer required. FIG. 14 illustrates thatcommunication between central processing system 1406 and card issuingbank's processing facility 1412 can be conducted through existing creditnetworks 1404. In addition to not requiring a switch, such as switch1116, in this configuration, a single large central processing system1406 can offer limited use support to a wide range of issuers, such asbank processing facility 1412. However, this configuration requiresincreased communication times and potentially increased communicationfees.

In another exemplary embodiment, the central processing system could beconstructed to be a part of the merchant acquirer, instead of the bankprocessing facility as shown in FIG. 11. This configuration would alsorequire the addition of a switch like switch 1116 but would reducecommunication delays and fees.

The limited use credit card number and remapping system may also be usedin connection with organizations other than banks. For example, thelimited use credit card number may be linked to organizations such asutilities, Internet service providers, telephone accounts, fixed ormobile, anonymous prepaid accounts and the like. With such otherorganizations, there would be no remapping to a master credit cardnumber, but rather to some other account number provided by theorganization.

Linking a limited use credit card number to other organizations isadvantageous for several reasons. First, the organization may have apre-existing relationship with the user of the limited use credit cardnumber. This relationship provides evidence of the user's credit historywith the organization, so no additional credit checks need to beperformed, which can be costly and time-consuming for the organization.Second, because the organization is already providing other services tothe user, a billing procedure is already established. The time and costassociated with establishing and implementing billing procedures hasalready been incurred. Minimal cost and effort is associated with addinga section to a billing statement for a limited use credit card number.

2.10. Remote Access Devices for Accessing Limited Use Numbers

A card holder may desire to access a list of limited usecredit/debit/charge card numbers where the limited use cards are notstored on the card holder's own computer. In the context of modernclient server architecture this represents one extreme of the situationwhere all information storage is at the server. The previous descriptionfor local storage indicates the situation of a client program with asignificant amount of local functionality. Between these two extremes arange of intermediary client server arrangements such as a “thin client”with minimal functionality obtaining limited use numbers from the serveras required. The combination of encryption and dynamic passwords, asdescribed herein, or any suitable alternative form of use identificationallows a card holder to have “multiple wallets”, i.e., a card holder canaccess limited use numbers from different devices, without the need totransmit credit card numbers.

As discussed above, software and limited use numbers can be issued viaelectronic communication media. In one embodiment, a card holder canaccess limited use credit card numbers during electronic transactionsvia a Remote Access Device, referred to herein as “RAD”, such as theOrbis Internet Card□. The overall layout of the RAD system 1500 is shownin FIG. 15 and a flow chart illustrating an exemplary method ofproviding remote access devices for accessing limited use credit cardnumbers is shown in FIG. 16. In general, the operation of the completesystem from registration to completion of a transaction follows.

When a user desires to register with RAD system 1500, the user submitsuser authentication information, the master account number and otheridentifying data for entry into a database 1502. (Step 1602). Toregister with RAD system 1500, the user must be a valid holder/user ofthe master credit card or account number. (Step 1604). Once registered,step 1606, the user obtains a RAD 1504, step 1608. RAD 1504 includes asoftware package to which enables communication with a remote accessdevice support server, referred to herein as a RAD support server 1506,such as the Nexus User Support Server□, to enable the issuance oflimited use card numbers.

When the user initiates communication with RAD support server 1506, step1610, RAD support server 1506 first authenticates the user. (Step 1612).If successfully authenticated, the user can then request a limited usenumber (step 1614) specifying any additional transaction limitationsdesired as discussed herein. (Step 1616) RAD support server 1506 issuesa request over a network to a central processing station 1508 for alimited use number with the one or more specified limitations. Thelimited use number provided in response to the request is associatedwith a specific RAD system user identification previously assigned tothe user.

The central processing station 1508 obtains the next available limiteduse number. (Step 1618). Once obtained, the limited use number, and thespecified limitations, is entered into database 1502 such that thelimited use number is associated with the user's information already indatabase 1502. (Step 1620). The limited use number is then transmittedto the RAD support server 1506 for issuance to the user via RAD 1504.(Step 1622). RAD software package 1504 displays the limited use number.The user can transfer this limited use number to a web site forinitiating a transaction. Transferring this number to a web site can beachieved by dragging and dropping the number onto the web page, bysoftware-simulated key-stroke entry, by “one-click” methods, or by othersuitable methods known to one skilled in the art.

When a merchant 1510 receives a transaction utilizing a limited usenumber from RAD system 1506, the transaction details are handled in thesame manner as an existing number since limited use card numbers sharethe same format as existing credit card numbers. The transaction detailsare transferred to the merchant acquirer and then routed onto theappropriate issuer on the basis of the leading digits of the limited usenumber, i.e., BIN, via central processing station 1508. The BIN isregistered with central processing station 1508 to ensure appropriaterouting.

As described above, central processing station 1508 verifies thevalidity of the limited use number and ensures that the transactionmeets all specified limitations. If the limited use number is valid andthe transaction met the specific limitations, central processing station1508 enters the master credit card number into the transaction messagein place of the limited use number. Central processing station 1508 thentransmits the transaction message to the issuer's processing facility1512 as a normal authorization request. The issuer's processing facility1512 transmits an authorization for the master card number, ifappropriate, to central processing facility 1508. Central processingfacility remaps the master card number to the limited use number and thetransaction message is transmitted to the originating merchant acquirerand then the merchant. Central processing station 1508 also updates thelimitations and validity of the limited use number according to thedetails of the transaction. The limitation and validity updating is bestdone following verification of available funds so that a limited usenumber with a cumulative value limit is only decremented in value if thetransaction can be completed. If limitation and validity updating isdone prior to checking for the availability/validity of the linked orprincipal account then certain updates will need to be reversed in thecase of a decline on the linked or principal account. This has a smallcomputational overhead. If the authorization was approved by theissuer's processing facility 1512, the user's purchase can proceed asnormal. If declined, a decline message is sent to the merchant.

For settlements, the same routing occurs with all transactions derivingfrom a limited use number obtained from RAD system 1500.

The above described system will now be discussed in greater detail.

The RAD system 1500 may be configured to provide the user with manyfeatures. The RAD system 1500 enables the user to have multiple anddifferent remote devices from which the user may access RAD supportserver 1506. In addition, it enables a user to have multiple credit cardaccounts with one or more issuers and to select from amount thesemultiple accounts. The RAD software package 1504 enables users to haveadditional passwords associated with an account if desired. Theadditional passwords can be used, for example, for children and can haveadditional pre-defined limitations such as a low dollar transactionlimits, e.g., $50.00, or merchant class restrictions, e.g., gasstations.

The RAD software package 1504 includes a simple intuitive interface forthe ease of the user, the appearance of which may be customizablewithout modification to the underlying code. The RAD 1504 may use imagesthat relate to the front and back of a credit card to provide key areasof functionality. The back of the RAD 1504 includes an interactive panelwith a magnetic stripe for providing additional information and/oradvertising panels. The interactive panel/stripe area provides forpassword entry and functional selections. Upon activation, the front ofRAD 1504 may be configured to provide additional functions, e.g., thoserequired to initiate an on-line purchase. As discussed herein, supplyinginformation required for on-line purchases can be automated in a numberof ways including “clicking and transferring” the information, “draggingand dropping” the information, or “one click shopping.”

In one embodiment, the RAD software package 1504 is configured to issuea sequence of paired numbers which are securely issued and activatedand/or decrypted by oral or written authorization, such as thecommunication of a password. These paired numbers include an identifiercode and a mask code. In order to retrieve a limited use number, a userat a remote device identifies himself or herself using his or her a RADsoftware 1504 by transmitting the identifier code, such as a dynamicpassword to RAD support server 1506. The RAD support server 1506compares the identifier code with the particular RAD software package1504 and accepts, or validates, the identifier code if appropriate. Ifvalid, RAD support server 1506 determines the matching mask code forthat identifier code from database 1502. The RAD support server 1506uses the mask code to encrypt the limited use card number as describedabove, and transmits this encrypted code to the user. The RAD software1504 decrypts the encrypted code using the known mask code andreconstructs the initial digits, the BIN number and the checksum digit.The RAD software 1504 then arranges this information and reconstructsthe limited use card number.

The RAD support server 1506 is an Internet based server that interfacesthe RAD 1504 and the central processing station 1508. The RAD supportserver 1506 receives requests for limited use numbers from users,validates each user, if appropriate, and supplies and validates limiteduse card numbers with specific limitations, as requested by each user,if appropriate. Such requests may be processed in any desired order,e.g., first come first served basis. The RAD support server 1506 mayalso be configured to provide for location identification verification,secure delivery of limited use numbers, automated completion of paymentfields in a merchant's web page order form, review of previoustransactions, access to additional issuer services and advertising. TheRAD location identification verification is verifying the physicalsource of the request for a limited use number, e.g., home, office, ATMmachine. This additional identification is evidence to limit a user'sability to deny a transaction. The RAD support server 1508 can beconfigured to require additional identification of the user if the RADis being used from a physical source which is unknown to the RAD supportserver or which has not been previously associated with the RAD by theuser.

To accomplish the above tasks, the RAD support server 1506 should have ahigh bandwidth Internet connection and highly secure firewalls toinsulate critical information from undesired access. Communicationsbetween the RAD support server 1506 and the RAD 1504 is may be Internetbased. Communication between the RAD support server 1506 and the centralprocessing station 1508 and the database 1502 may be secured via privatenetworks for additional security. In addition, to provide for additionalsecurity, the RAD support server 1506, the central processing station1508 and database 1502 may be located at the same physical location, forexample, the issuer's processing facility or some other facility whichmeets the standards set for banking processing facilities.

Communication between the RAD 1504 and the RAD support server 1506 canuse industry standard security protocols appropriate to the platform.For example, secure socket layer (SSL) encryption may be used in thecase of communication by a personal computer of the Internet.Alternatively, one of the encryption schemes described herein may beimplemented alone or in combination with password protection and/orsmart card user authentication. Such communication security can beselectable by the issuer. For example, issuers can select what type ofcommunication security they desire from a range of options.

3. Controlled Payment Number (CPN) Applications

As can be seen from the above, the described limited-use credit cardnumbers can be provided with user defined controls on how the numberscan be used. Hence, the phrase “controlled payment numbers” describesproducts which embody the invention described herein.

To appreciate how a software and hardware platform embodying theinvention can be used to generate a range of payment products that spanthe virtual, wireless and real worlds it is necessary to consider thecomponents of the complete platform and how these can be used in variouscombinations. To a large extent, remarkably distinct payment productscan be derived using the existing platforms such as the RAD system 1500of FIG. 15 in a range of configurations. Addition of standard additionalcomponents and interfaces further broadens the potential scope. The RADsystem platform 1500 has been designed from the outset to support suchapplications. This provides a rapid development path for new paymentproducts since development requirements are limited primarily todesigning new client side components for configuring and controlling CPNpayments.

At the heart of the CPN platform are a number of core components:

-   -   A card number generating and allocation system (e.g., support        server 1508) that allows for additional controls to allocated to        the cards in a dynamic manner.    -   A card issuing process for distribution of CPN's to users that        supports industry standard protocols, such as shown in FIGS. 5        and 6.    -   A card authorization and settlement process (e.g., FIGS. 7        and 8) that provides additional verification and validation of        cards against the current set of controls that have been set up        for that card.    -   A mechanism for relating a specific CPN to an existing credit        card, debit card or general financial account (e.g., FIGS. 11,        12 and 13).

The platform may be implemented with part as a personal computerconnected to the Internet to provide communication with the card issuer.The customer can set a range of limitations as determined by the issuerand the card number is issued in virtual form to the users computer(usually) for immediate use.

This arrangement is ideal for e-commerce applications but, by alteringhow the core component functions are implemented and integrated, a rangeof additional applications can be produced. These applications can bebroadly divided into:

1. Card present Transactions;

2. MOTO (Mail Order and Telephone Order); and

3. Wireless applications.

Specifically these applications can be implemented by varying: (1) thepatterns of how the controls on specific numbers are combined, (2) thecontrols available to user(s), (3) who sets the controls and when, (4)how the controls are communicated to the processing system, (5) thecommunication device(s) or channels used to deliver an issued CPN to theuser, (6) the form in which the CPN is issued (virtual via software,voice generated, text message, paper receipt, paper credit card card,plastic credit card), and (7) the form in which the CPN is presented tothe merchant.

The core transaction processing system for authorization and settlementis not altered to any significant degree by any of these implementationvariations. In addition most of the core back end systems for numbergeneration, account generation, linkage to other accounts, customerservice and maintenance remain unaltered. The architecture for issuingnumbers to users supports a range of interfaces so the same architecturecan support computer based, phone, interactive TV or internal bankissuing for physical implementations. The high degree of re-usability ofcore platform components is a key advantage in supporting the commercialviability of these other products.

The following sections elaborate on these principles to indicate how inpractical terms the system would operate and how a consumer would usethe system in the various manifestations.

3.1 Card Present Applications

There are considerable opportunities to create new payment products byissuing fixed number plastic cards with flexibility and control providedby the present invention. There are applications of this approach inboth the consumer and business markets.

In these applications, new payment products can be created by placing“intelligence” within the card processing system. A critical additionalstep is the creation of new communication channels between theseprocessing systems and a card issuer/card holder.

These communication channels which can include PC computer interfaces,PDA interfaces, mobile phone/telephony interfaces, ATM interfaces.

In combination with an issuer's capability to configure specific cardproducts, these additional dynamic control features provide a mechanismfor a traditional plastic payment card to be turned into a range of newproducts. In effect, the present invention creates “instantlyconfigurable plastic payment cards”. This capability can be combinedwith conventional credit cards, debit cards and pre-paid cards.

3.1.1 Consumer Applications

There are range of consumer applications of which a few are listed here.

Teen Card

Given to a teenager, for example, this card has a pre-set limittransaction amount and/or must be spent at a particular merchant ormerchants (or merchant type or types). A parent can receive feedback oncard usage and change the spending power by computer interface or mobilephone at any time. This greatly enhances the control provided byexisting pre-paid teen cards.

Gift Certificate Card

Given to someone to spend with a pre-set limit and can be limited to aparticular merchant or merchant type. These merchants can be Visa or M/Ccompatible and protected by signature.

Product Rebates

A limited use card could be issued with a product that has no value butcan be activated by registering the product on-line for instance. Thecard is then loaded with the product rebate and can be used to purchasesomething on-line or at a retail store limited to the amount of therebate. This will greatly reduce costs to administer a rebate programassociated with e.g., issuing and mailing a check.

Insurance Card

A limited use card could be issued with an insurance policy or by aloss-adjuster at a visit following a claim. The company or the lossadjuster could provide instant card activation by computer or mobilephone to allow the consumer to spend an amount appropriate to immediateneeds.

3.1.2 Corporate Applications

For corporate applications the controls inherent in CPN technologytogether with the capability to support a range of communication systemsto set up controls for a specific account provide a powerful businesstool. Examples include:

Company Bonus

Given to employees as a bonus this limited use credit card number can beused anywhere Visa or M/C is accepted or alternatively limited to aparticular merchant or merchant type. Cards can be issued and thecompany can set the reward amounts via a PC-computer interface. Allcharges can be billed to a central company account.

Company Expense Travel Account

This limited use card can be given to employees for specific trips. Theexpense budget and types of expense can be set by the employer at thestart of the trip and the account deactivated until the next trip.

Purchasing Account with Integrated PO Request

This limited use card can be given to employees company purchases andpre-configured for specific rules (e.g., maximum single purchase amountand monthly expenditure). To extent these rules apply the employee canmake a request via a PC or mobile phone to the company purchasingsystem. If approved, the company system can automatically extend thepurchasing capability of the specific card and the employee receives aconfirmation and purchase order number.

3.1.3 Mail Order/Telephone Order (MOTO)

The acceptability of CPN's at any VISA/Mastercard/Europay acceptingmerchant is a key advantage of CPN technology. This means that theexisting computer based system can be for mail order and telephone orderwith any alterations. Having said that, the current system is notspecifically directed at MOTO users and users may not appreciate thiscapability. In addition many existing MOTO users may not have access tothe Internet at the time of placing a MOTO order or indeed have Internetaccess at all. Without a credit card, telephone orders can be almostimpossible. All the manifestations described below could also beprovided linked to a bank account or pre-paid account.

The following represent specific products more specifically marketed theMOTO market. As with the potential cross over between Internet and MOTOusage, these MOTO products could also be used in Internet applications.

3.1.4 Telephone Interfaces for CPN Delivery

Mobile telephony interfaces can allow both WAP (Web Access Protocol) andi-mode interaction with servers providing the CPN capabilities. Thisprovides for authentication by password or PIN and delivery of a CPN viaa simple interface for display on the screen. CPN's can also be issuedby SMS (Silicon Integrated Systems), which has the additional benefit ofproviding automatic storage of the number for later use. Review ofstatements is also possible via this interface. The core functionalityfor MOTO orders are very similar to Internet orders and so no majordifferences are required in terms of additional functionality, thoughthe functionality is best limited in line with the small screens ofcurrent mobile telephones. This application would also be well suited toweb-kiosk applications where users may not want to enter authenticationcredentials into public systems. There is currently increasing interestin “in-store” kiosks to provide additional product lines. Thisimplementation of the web-kiosk is designed specifically for makingpurchases and the mobile CPN will ideally suit such a combined “clicksand mortar” transaction.

This application, the mobile CPN, provides a suitable platform for MOTOor Internet payments. In this situation the mobile phone is used as aprivate and personal means of authenticating the user and delivering thenumber to the user.

3.1.5 Alternative Web Access Devices

It is expected that web access will increasingly involve non-PC devicessuch as PDA's, set-top TV boxes, Interactive TV and “smart” consumerdevices. The CPN platform architecture provides for seamless integrationof a wide range of web-access devices into a standard Orbiscomimplementation. The CPN platform can be used with interactive TV, whichprovides for integration of the purchasing process with “TV browsing”.

3.1.6 MOTO/Web Only Plastic/Paper Card

Issuing a MOTO/Web only card with no embossed figures can be implementedwithin the CPN platform with the export of CPN's to a card productionprocess.

In combination with the CPN platform this approach has a number ofadvantages even though the number is fixed and used for a number oftransactions.

-   -   Greatly reduced re-issue costs for compromised cards. This is        especially true in a chip environment where card re-issue costs        are greatly increased. Also it greatly reduces the inconvenience        involved in re-issuing a card.    -   A physical card is useful when collecting tickets for example.    -   Additional controls from the Orbiscom platform provide for the        flexible control of the overall limit.    -   Controls can be applied to create specific mail order merchant        cards with incentives by applying merchant ID controls.    -   The CPN platform provides for simple integration into an        existing credit facility or account without the need to create a        separate credit line.

Controls can be set-up by an issuer or via a telephone or computerinterface as with other limited use credit card number products. Theseinterfaces could provide for additional functions such as on-linestatements.

3.1.7 MOTO-Only Account Number Distribution Options

In addition to the above card based solution, a system of distributingnumbers without cards could be incorporated in the paper billingdistribution system. This could involve printing an additional number(s)on a statement or other paper document as explained above.

Customers could also be sent a new MOTO only number in the form of asticker that could be attached to an existing card, on expiry the numberis simply removed. An alternative MOTO number could also be printed onthe back of an existing credit card when a new card is issued.

3.1.8 ATM Delivery of CPN Numbers and or Cards

The ATM network provides an existing integrated network that provides:

-   -   user authentication    -   a configurable user interface    -   an interface to process customer requests    -   a screen and printing system to provide visual and printed        information for the    -   capability for delivering other physical materials (cash, stamps        and potentially magnetic stripe cards).

This provides a means for providing CPN numbers or cards for a range ofcard-not present applications. This route is particularly suitable forpeople who do not possess a credit card but wish to purchase goods overthe Internet, telephone or mail order.

3.1.9 Unique CPN Transactions for MOTO

The above physical manifestations of the Orbiscom platform for MOTO usea fixed number with variable controls. It is also possible to issue aseries of numbers on a single card or device that users use one at atime. A mechanism is required to ensure that user can simply keep trackof numbers that have been used. A range of options are possible forincluding peel of labels where after use a CPN label is removedrevealing an additional number underneath. Alternatively scratch offcards like lottery cards could be used to ensure that a number is onlyrevealed when a user wishes to use the card.

4. Wireless Card Present Applications

CPN payments can be presented by developments in wireless and telephonyapplications most notably Bluetooth and other emerging short rangewireless technologies (e.g., Ultra Wide Band) and the advances in mobilephone capabilities.

The use of Bluetooth-enabled smart card readers communicating with POS(point of sale) terminals, or mobile network operators allowing users tobuy products and pay for them on their bills. However, smart cards havenot yet been widely deployed, and mobile network operators do not have atrack record in e-commerce payments. A better solution is offered by thepresent invention, which utilizes the existing credit card network.

In operation, a Bluetooth enabled WAP phone, of instance, would be usedto retrieve a CPN. The following steps would take place:

-   1. The user would connect to the issuer's website using the WAP    phone, and would log in and request a CPN.-   2. The issuer's web server would communicate with the Orbiscom    server, which would issue an CPN with the required controls and link    to the users account (either set by the user at the time or using    pre-determined default values).-   3. The CPN would be returned to the user's WAP phone over the mobile    network.-   4. The user would instruct the Bluetooth-enabled WAP phone to    discover the POS service of the POS terminal.-   5. The phone and POS terminal would establish a Bluetooth    connection, using suitable authentication security.-   6. The phone would beam the CPN to the POS terminal.

Signature Authentication

Card Present transactions are characterized by visual signatureauthentication, in which the signature on the credit card is compared tothe signature on the sales voucher. A different kind of authenticationis required by wireless Card Present transactions. The unique SIM cardin every mobile phone can be used as an identification card, andtechnologies such as fingerprint identification and voice recognitionwill insure that a stolen phone cannot be used by anyone other than theowner.

Mobile POS

As well as the familiar card present situations, such as payment at arestaurant, the growth of wireless mobile networks has made possible thedevelopment of mobile POS terminals. Up to now, mobile retailers andservice providers have been at a disadvantage as the world moves towardsa system of cashless transactions. Mobile POS terminals will allowcredit card payments on public transport, in taxis, and at open airmarkets, as well as allowing. It will also be possible to pay by creditcard for services such as pizza and grocery delivery, and appliancerepair in the home. Card present CPN applications will allow payment inall of these situations.

Smart Cards

As credit cards migrate to smart card technology, the paymentpossibilities will broaden. Smart cards are an ideal method ofauthenticating users with a card issuer during issuing of CPN numbers ina virtual environment. The transaction specific nature of CPN paymentsenables linkage of a smart card authentication step to a specificpayment without requiring merchants or acquirers to implementauthentication technology.

In addition several additional possibilities exist for storing CPNnumbers in smart cards for card present use. For example, Ericsson'sprototype Wireless Wallet is a real wallet that contains a smart cardreader and a WAP server, and allows the user to browse the cards in thewallet from a WAP phone. CPNs could be stored on a smart card for usewhen needed. You could simply browse the cards in the wallet, and selectthe CPN to be sent to the POS terminal, all without taking the walletfrom your pocket.

3G Phones

Third generation mobile phones and hand-held devices will be capable ofrequesting and storing CPN's, of displaying internet content much richerthan the current WAP phones, and of running feature rich applicationssuch as the CPN system in accordance with the present invention. Themarch of technology will continue to create new opportunities for cardpayments, and CPN technology will be there to provide the securityneeded.

While the foregoing description makes reference to particularillustrative embodiments, these examples should not be construed aslimitations. Not only can the inventive system be modified for othercard numbered systems; it can also be modified for other computernetworks or numbering schemes. Thus, the present invention is notlimited to the disclosed embodiments, but is to be accorded the widestscope consistent with the claims below.

What is claimed:
 1. A method for processing a transaction initiated by acustomer presenting a personalized gift card number to a merchant, themethod comprising the steps of: associating, in a database, a pluralityof merchant identifiers and a predetermined amount with the personalizedgift card number; receiving, in a central processing system, thepersonalized gift card number, a transaction amount, and a merchantidentification number electronically routed from the merchant;determining electronically whether the personalized gift card number hasbeen deactivated because the predetermined amount has been satisfied;electronically determining whether the merchant identification numbercorresponds to one of the plurality of merchant identifiers associatedwith the personalized gift card number; electronically determiningwhether authorization can be obtained against the personalized gift cardnumber based on the merchant identification number determining step, thereceived transaction amount, and the predetermined amount; andelectronically transmitting a signal to the merchant with the results ofthe authorization determining step for the personalized gift cardnumber.
 2. The method of claim 1, further comprising: transmitting asignal to the merchant denying authorization if the personalized giftcard number has been deactivated.
 3. The method of claim 1, furthercomprising: authorizing the transaction based on the results of theauthorization determining step.
 4. The method of claim 3, furthercomprising: subtracting the transaction amount from the predeterminedamount associated with the personalized gift card in the database. 5.The method of claim 1, further comprising: declining authorization ofthe transaction based on the results of the authorization determiningstep.
 6. The method of claim 1, wherein the personalized gift cardnumber is associated with a master account number of an account holder.7. The method of claim 6, further comprising: electronicallytransmitting a signal to a facility which issued the personalized giftcard number, the signal including original transaction details but withthe personalized gift card number remapped to be the master accountnumber if the personalized gift card number has not been deactivated,wherein the authorization determining step includes electronicallydetermining whether authorization can be obtained against the masteraccount number.
 8. The method of claim 7, wherein the personalized giftcard number is linked to an organization selected from a groupconsisting of: a utility, a public network service provider, a telephonecompany, a bank account, a prepaid account, and a credit card issuer. 9.The method of claim 8, further comprising: transmitting a signal to theorganization which is linked to the personalized gift card number, thesignal including the original transaction details if the personalizedgift card number has not been deactivated; performing a credit check todetermine whether authorization can be obtained against the personalizedgift card number; and transmitting a signal to the merchant with theresults of the authorization determining step for the personalized giftcard number.
 10. The method of claim 1, wherein the predetermined amountcorresponds to a funding amount for a predetermined number oftransactions.
 11. The method of claim 10, wherein the predeterminednumber of transactions is one of: a single transaction, a plurality oftransactions, and a number of recurring transactions.
 12. A method forconducting a transaction involving a personalized gift card number, themethod comprising the steps of: initiating a transaction by a customerpresenting the personalized gift card number to a merchantelectronically or in person; electronically routing the personalizedgift card number to a central processing system; determiningelectronically whether the personalized gift card number has beendeactivated because a predetermined amount associated with thepersonalized gift card number has been satisfied; electronicallydetermining whether a merchant identification number associated with themerchant corresponds to one of a plurality of merchant identifiersassociated with the personalized gift card number; electronicallydetermining whether authorization can be obtained against thepersonalized gift card number based on the merchant identificationnumber determining step, the predetermined amount associated with thepersonalized gift card number, and a transaction amount of thetransaction; and electronically transmitting a signal to the merchantwith the results of the authorization determining step for thepersonalized gift card number.
 13. A method for implementing apersonalized gift card system, the method comprising: maintaining a poolof credit card numbers which share identical formatting; assigning atleast one credit card number from the pool of credit card numbers to bea personalized gift card number which is deactivated upon use of apredetermined amount which occurs subsequent to assignment of the atleast one credit card number; associating the predetermined amount withthe personalized gift card number; determining whether to deactivate thepersonalized gift card number when the personalized gift card number wasused to perform a transaction, and for generating a deactivation commandin response thereto, wherein the determining step of whether todeactivate the personalized gift card number determines whether thepredetermined amount has been used to fund transactions, and if so,generates the deactivation command when the predetermined amount hasbeen used; and deactivating the personalized gift card number based onthe deactivation command, wherein the personalized gift card number isvalid for use at a plurality of merchants for at least one financialtransaction totaling up to the predetermined amount.
 14. The method ofclaim 13, further comprising: associating a master account number withthe personalized gift card number, while ensuring that the masteraccount number cannot be discovered on the basis of the personalizedgift card number.
 15. The method of claim 13, wherein the predeterminedamount corresponds to a funding amount for a predetermined number oftransactions.
 16. The method of claim 15, wherein the predeterminednumber of transactions is one of: a single transaction, a plurality oftransactions, and a number of recurring transactions.
 17. The method ofclaim 13, further comprising: transmitting, to a receiver, apersonalized gift card associated with the personalized gift card numberin electronic or physical form.
 18. The method of claim 13, furthercomprising: associating the personalized gift card number with a messagereceived from a gift provider, wherein the message is displayed to areceiver of the personalized gift card number upon use of thepersonalized gift card number.
 19. A system for processing a transactioninitiated by a customer presenting a personalized gift card number to amerchant, the system comprising: a database configured to store aplurality of merchant identifiers and a predetermined amount associatedwith the personalized gift card number; a receiving device configured toreceiving the personalized gift card number, a transaction amount, and amerchant identification number electronically routed from the merchant;a processing device configured to determine electronically whether thepersonalized gift card number has been deactivated because thepredetermined amount has been satisfied, electronically determinewhether the merchant identification number corresponds to one of theplurality of merchant identifiers associated with the personalized giftcard number, and electronically determine whether authorization can beobtained against the personalized gift card number based on the merchantidentification number determining step, the received transaction amount,and the predetermined amount; and a transmitting device configured toelectronically transmit a signal to the merchant with the results of theauthorization determination for the personalized gift card number. 20.The system of claim 19, wherein the transmitting device is furtherconfigured to electronically transmit a signal to the merchant denyingauthorization if the personalized gift card number has been deactivated.21. The system of claim 19, wherein the processing device is furtherconfigured to authorize the transaction based on the results of theauthorization determination.
 22. The system of claim 21, wherein theprocessing device is further configured to subtract the transactionamount from the predetermined amount associated with the personalizedgift card number.
 23. The system of claim 19, wherein the processingdevice is further configured to decline authorization of the transactionbased on the results of the authorization determination.
 24. The systemof claim 19, wherein the personalized gift card number is associatedwith a master account number of an account holder.
 25. The system ofclaim 24, wherein the transmitting device is further configured toelectronically transmit a signal to a facility which issued thepersonalized gift card number, the signal including original transactiondetails but with the personalized gift card number remapped to be themaster account number if the personalized gift card number has not beendeactivated, and wherein the authorization determination includeselectronically determining whether authorization can be obtained againstthe master account number.
 26. The system of claim 25, wherein thepersonalized gift card number is linked to an organization selected froma group consisting of: a utility, a public network service provider, atelephone company, a bank account, a prepaid account, and a credit cardissuer.
 27. The system of claim 26, wherein the transmitting device isfurther configured to electronically transmit a signal to theorganization which is linked to the personalized gift card number, thesignal including the original transaction details if the personalizedgift card number has not been deactivated, the processing device isfurther configured to perform a credit check to determine whetherauthorization can be obtained against the personalized gift card number,and the transmitting device is further configured to electronicallytransmit a signal to the merchant with the results of the authorizationdetermination for the personalized gift card number.
 28. The system ofclaim 19, wherein the predetermined amount corresponds to a fundingamount for a predetermined number of transactions.
 29. The system ofclaim 28, wherein the predetermined number of transactions is one of: asingle transaction, a plurality of transactions, and a number ofrecurring transactions.
 30. A system for conducting a transactioninvolving a personalized gift card number, the system comprising: aninitiating device configured to initiate a transaction by a customerpresenting the personalized gift card number to a merchantelectronically or in person; a routing device configured toelectronically route the personalized gift card number to a centralprocessing system; a processing device configured to determineelectronically whether the personalized gift card number has beendeactivated because a predetermined amount associated with thepersonalized gift card number has been satisfied, electronicallydetermine whether a merchant identification number associated with themerchant corresponds to one of a plurality of merchant identifiersassociated with the personalized gift card number, and electronicallydetermine whether authorization can be obtained against the personalizedgift card number based on the merchant identification numberdetermination, the predetermined amount associated with the personalizedgift card number, and a transaction amount of the transaction; and atransmitting device configured to electronically transmit a signal tothe merchant with the results of the authorization determination for thepersonalized gift card number.
 31. A personalized gift card system,comprising: a database configured to store a pool of credit card numberswhich share identical formatting; an assignment device configured toassign at least one credit card number from the pool of credit cardnumbers to be a personalized gift card number which is deactivated uponuse of a predetermined amount which occurs subsequent to assignment ofthe at least one credit card number, an associating device configured toassociate the predetermined amount with the personalized gift cardnumber; and a processing device configured to determine whether todeactivate the personalized gift card number when the personalized giftcard number was used to perform a transaction, and to generate adeactivation command in response thereto, wherein the determination ofwhether to deactivate the personalized gift card number determineswhether the predetermined amount has been used to fund transactions, andif so, generates the deactivation command when the predetermined amounthas been used, and deactivate the personalized gift card number based onthe deactivation command, wherein the personalized gift card number isvalid for use at a plurality of merchants for a plurality of financialtransactions totaling up to the predetermined amount.
 32. The system ofclaim 31, wherein the associating device is further configured toassociate a master account number with the personalized gift cardnumber, while ensuring that the master account number cannot bediscovered on the basis of the personalized gift card number.
 33. Thesystem of claim 31, wherein the predetermined amount corresponds to afunding amount for a predetermined number of transactions.
 34. Thesystem of claim 33, wherein the predetermined number of transactions isone of: a single transaction, a plurality of transactions, and a numberof recurring transactions.
 35. The system of claim 31, furthercomprising a transmitting device configured to transmit, to a receiver,a personalized gift card associated with the personalized gift cardnumber in electronic or physical form.